简体中文（ZH-CN）English（EN）繁体中文（ZH-TW）日本語（JA）한국어（KO）Melayu（MS）Français（FR）Deutsch（DE）
집
기사
Q&A
강의
주제
다운로드
게임
사전
최근 업데이트

집  >  기사  >  웹 프론트엔드  >  프런트 엔드, HTT, 컴퓨터 및 네트워크

프런트 엔드, HTT, 컴퓨터 및 네트워크

php中世界最好的语言
php中世界最好的语言원래의
2018-05-25 11:52:212439검색

이번에는 프론트엔드, HTT, 컴퓨터 및 네트워크에 대해 소개하겠습니다. 프론트엔드, HTT, 컴퓨터 및 네트워크에 대해 주의할 점은 무엇입니까?

풀엔드 엔지니어가 알아야 할 컴퓨터 네트워크 지식

1. 네트워크 - http 메시지에 대한 자세한 설명

1. 분류

  1. 응답 메시지

  2. 2.

    3. (1) 요청 메시지

HTTP 요청 메시지는

요청 라인, 요청 헤더, 빈 라인 및 요청 데이터

로 구성됩니다.

요청 라인

    2. 은 3개 필드로 구성됩니다. 필드, URL 필드 및 HTTP 프로토콜 필드는 공백으로 구분됩니다.

  • 예: GET /index.html HTTP/1.1.

  • HTTP 프로토콜의 요청 방법에는 GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE 및 CONNECT가 포함됩니다.

요청 헤더

    2. 요청 헤더는 키워드/값 쌍으로 구성되며 한 줄에 한 쌍씩, 키워드와 값은 영어 콜론 ":"으로 구분됩니다.

  • 요청 헤더는 클라이언트의 요청에 대해 서버에 알립니다.

  • 일반적으로 사용되는 요청 헤더:

  • Accept는 허용되는 콘텐츠 유형을 설정합니다. Accept: text/plain;

  1. Accept-Charset 허용되는 문자 인코딩 설정: Accept-Charset: utf-8;Accept: text/plain;

  2. Accept-Charset 设置接受的字符编码:Accept-Charset: utf-8;

  3. Accept-Encoding 设置接受的编码格式:Accept-Encoding: gzip, deflate;

  4. Accept-Language 设置接受的语言:Accept-Language: en-US;

  5. Cache-Control 设置请求响应链上所有的缓存机制必须遵守的指令:Cache-Control: no-cache;

  6. Connection 设置当前连接和hop-by-hop协议请求字段列表的控制选项:Connection: keep-alive;

  7. Content-Length 设置请求体的字节长度:Content-Length: 348;

  8. Content-Type 设置请求体的MIME类型（适用POST和PUT请求）:Content-Type: application/x-www-form-urlencoded;

  9. Cookie 设置服务器使用Set-Cookie发送的http cookie:Cookie: $Version=1; Skin=new;;

  10. Host 设置服务器域名和TCP端口号，如果使用的是服务请求标准端口号，端口号可以省略:Host: en.wikipedia.org:8080;

  11. Origin 标识跨域资源请求（请求服务端设置Access-Control-Allow-Origin响应字段）:Origin: http://www.example-social-network.com;

  12. Expires 设置响应体的过期时间:Expires: Thu, 01 Dec 1994 16:00:00 GMT;

  13. ETag 特定版本资源的标识符，通常是消息摘要:ETag: "737060cd8c284d8af7ad3082f209582d";

  14. Last-Modified 设置请求对象最后一次的修改日期:Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Accept-Encoding 허용되는 인코딩 형식 설정: Accept-Encoding: gzip, deflate;

  1. Accept-Language 허용되는 언어를 설정합니다: Accept-Language: en-US;

    2. Cache-Control 요청 응답 체인의 모든 캐시를 설정합니다. 메커니즘은 다음을 준수해야 합니다. Cache-Control: no-cache

  • Connection 현재 연결 및 홉별 프로토콜 요청 필드 목록에 대한 제어 옵션 설정: 연결: 유지 - 살아있는;

    Content-Length는 요청 본문의 바이트 길이를 설정합니다. Content-Length: 348;

  1. Content-Type은 요청의 MIME 유형을 설정합니다. body(POST 및 PUT 요청에 적용 가능):Content-Type: application/x-www-form-urlencoded;

    Cookie는 Set-Cookie를 사용하여 서버에서 보낸 http 쿠키를 설정합니다.Cookie: $Version= 1; Skin=new;;

    • Host는 서버 도메인 이름과 TCP 포트 번호를 설정합니다. 서비스 요청 표준 포트 번호를 사용하는 경우 포트 번호를 생략할 수 있습니다. 호스트: en.wikipedia.org: 8080;

Origin은 교차 도메인 리소스 요청을 식별합니다(서버에 Access-Control-Allow-Origin 응답 필드를 설정하도록 요청):Origin : http://www.example-social-network.com ;

  1. Expires는 응답 본문의 만료 시간을 설정합니다.Expires: 1994년 12월 1일 목요일 16:00:00 GMT;

  2. ETag는 특정 버전 리소스의 식별자입니다. 일반적으로 메시지 요약은 다음과 같습니다. ETag: "737060cd8c284d8af7ad3082f209582d";

    3. Last-Modified는 버전 리소스의 마지막 수정 날짜를 설정합니다. 요청 객체: 최종 수정: 1994년 11월 15일 화요일 12:45: 26 GMT;

  • 공백 라인

      • 마지막 요청 헤더 뒤에는 빈 줄, 캐리지 리턴 및 줄 바꿈 문자를 보내 아래에 더 이상 요청 헤더가 없음을 서버에 알립니다.

    • 요청 본문(데이터)

    • 요청 데이터는 GET 방식이 아닌 POST 방식으로 사용됩니다. POST 방법은 고객이 양식을 작성해야 하는 상황에 적합합니다. 요청 데이터와 관련하여 가장 일반적으로 사용되는 요청 헤더는 Content-Type 및 Content-Length입니다.

  • (2), 응답 메시지

    HTTP 응답도 상태 줄, 메시지 헤더, 빈 줄, 응답 본문의 네 부분으로 구성됩니다. 🎜🎜🎜🎜응답의 유일한 차이점은 요청 정보가 첫 번째 줄의 상태 정보로 대체된다는 것입니다. 상태 줄은 상태 코드를 제공하여 요청된 리소스를 설명합니다. 🎜🎜🎜🎜🎜상태 줄🎜🎜🎜🎜🎜🎜🎜형식: 서버 HTTP 프로토콜 버전 응답 상태 코드 상태 코드에 대한 텍스트 설명 🎜🎜🎜🎜상태 코드는 세 자리 숫자로 구성되며 첫 번째 숫자는 응답을 정의합니다. 카테고리이며 5개의 가능한 값이 있습니다. 🎜🎜🎜🎜🎜1xx: 지침 정보-요청이 수신되었으며 계속 처리되고 있음을 나타냅니다. 🎜🎜🎜🎜2xx: 성공--요청이 성공적으로 수신되고 이해되었으며 승인되었음을 나타냅니다. 🎜🎜🎜🎜3xx: 리디렉션 - 요청을 완료하려면 추가 작업을 수행해야 합니다. 🎜🎜🎜🎜4xx: 클라이언트 오류--요청에 구문 오류가 있거나 요청을 이행할 수 없습니다. 🎜🎜🎜🎜5xx: 서버 측 오류 - 서버가 합법적인 요청을 이행하지 못했습니다. 🎜🎜🎜🎜🎜일반 상태 코드: 🎜

    • 200 OK: 요청이 성공했고 모든 것이 정상임을 나타냅니다.

    • 301 영구적으로 이동됨: 리디렉션, 고객이 요청한 문서가 다른 곳에 있고 새 URL이 위치 헤더에 제공되며 브라우저는 자동으로 새 URL에 액세스합니다.

    • 302 발견: 임시 리디렉션, 301과 유사하지만 새 URL은 영구 URL이 아닌 임시 대체 URL로 간주되어야 합니다.

    • 304 수정되지 않음: 클라이언트에 버퍼링된 문서가 있고 조건부 요청을 발행했습니다. 서버는 클라이언트에게 원래 버퍼링된 문서를 계속 사용할 수 있음을 알려줍니다.

    • 400 잘못된 요청: 요청에 구문 오류가 있습니다.

    • 403 금지됨: 리소스를 사용할 수 없습니다.

    • 404 찾을 수 없음: 지정된 위치의 리소스를 찾을 수 없습니다.

    • 405 메서드가 허용되지 않음: 요청 메서드(GET, POST, HEAD, 삭제, PUT, TRACE 등)가 지정된 리소스에 적용 가능하지 않습니다.

    • 500 내부 서버 오류: 서버에 예상치 못한 상황이 발생하여 고객의 요청을 완료할 수 없습니다.

    • 501 Not Implemented: 서버가 request

를 구현하는 데 필요한 기능을 지원하지 않습니다. (3) post 요청과 get 요청

  1. GET 제출의 차이점에 대해 요청한 데이터는 다음에 추가됩니다. URL(즉, HTTP 프로토콜 헤더 에 데이터 배치) POST 제출: 제출된 데이터를 HTTP 패키지 의 본문에 배치합니다. 전송되는 데이터의 수:

    3. HTTP 프로토콜은 전송되는 데이터의 크기를 제한하지 않으며, HTTP 프로토콜 사양은 URL의 길이를 제한하지 않습니다.

    4. 실제 개발의 주요 제한 사항은 다음과 같습니다.

  • GET: 특정 브라우저와 서버에는 URL 길이에 대한 제한이 있습니다. 예를 들어 IE의 URL 길이 제한은 2083바이트(2K+35)입니다. Netscape, FireFox 등 다른 브라우저의 경우 이론적으로 길이 제한이 없으며 운영 체제 지원에 따라 제한이 달라집니다. 따라서 GET을 제출할 때 전송되는 데이터는 URL 길이에 따라 제한됩니다.

  • POST: URL을 통해 값이 전달되지 않기 때문에 이론적으로 데이터는 무제한입니다. 그러나 각 웹 서버는 실제로 제출 후 데이터의 크기에 대한 제한을 규정하고 있으며 Apache와 IIS6에는 자체 구성이 있습니다.

    • 4. 보안:

    • POST가 GET보다 더 안전합니다.

GET을 통해 데이터를 제출하면

  • (1) 로그인 페이지가 브라우저에 의해 캐시될 수 있고

  • (2) 다른 사람이 볼 수 있기 때문에 사용자 이름과 비밀번호가 URL에 일반 텍스트로 표시됩니다. 브라우저 기록을 저장하면 다른 사람이 귀하의 계정과 비밀번호를 얻을 수 있습니다

  • (4), http 및 https

  • 1. HTTP 및 HTTPS

HTTP 프로토콜은 일반적으로 TCP 프로토콜 위에 전달됩니다. TCP와 보안 프로토콜 레이어(SSL 또는 TSL)를 추가하면 우리가 흔히 HTTPS라고 부르는 것이 됩니다

HTTP의 기본 포트 번호는 80이고 HTTPS의 포트 번호는 443

  • 입니다.

    2. HTTPS가 안전한 이유

    • 네트워크 요청은 중간에 많은 서버 라우터를 통해 전달되어야 하기 때문입니다. 중간 노드는 정보를 변조할 수 있으며, HTTPS를 사용하는 경우 키는 사용자와 최종 스테이션 사이에만 있습니다. https가 http보다 안전한 이유는 전송에 SSL/TLS 프로토콜을 사용하기 때문입니다. 여기에는 인증서, 오프로딩, 트래픽 전달, 로드 밸런싱, 페이지 적응, 브라우저 적응, 참조 전달 등이 포함됩니다. 전송 프로세스의 보안 보장

3. HTTP 2.0 소개

    • HTTP/2는 클라이언트가 필요로 하기 전에 서버가 데이터를 푸시할 수 있는 "서버 푸시" 개념을 도입합니다. 성능을 향상시키기 위해 클라이언트 캐시를 사용합니다.

HTTP/2는 더 많은 암호화 지원을 제공합니다.

  • HTTP/2는 다중화 기술을 사용하여 하나의 연결에서 여러 메시지를 동시에 교환할 수 있습니다.

  • 헤더 압축이 추가되므로 매우 작은 요청의 경우에도 요청 및 응답 헤더는 대역폭의 작은 부분만 차지합니다.

  • 4 http 단점:

    • 일반 텍스트가 아닌 경우 통신을 위해 암호화되면 콘텐츠가 도난당할 수 있습니다.

통신 당사자의 신원이 확인되지 않으면 위장될 수 있습니다.

  • 메시지의 무결성을 확인할 수 없으며 변조될 수 있습니다.

  • https는 암호화 처리(보통 SSL 보안 통신 회선) + 인증 + 무결성 보호

  • 5. HTTP/2와 HTTP/1.x의 주요 차이점

텍스트 프로토콜이 아닌 바이너리 프로토콜 , 더 간결하고 효율적입니다

각 도메인에 하나의 다중화 연결만 사용하세요

  • 헤더 정보를 압축하여 오버헤드를 줄입니다

  • 서버가 적극적으로 클라이언트 캐시에 응답을 푸시하도록 허용

(5), http 상태 코드 

 简单版
    [
        100  Continue   继续，一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息
        200  OK         正常返回信息
        201  Created    请求成功并且服务器创建了新的资源
        202  Accepted   服务器已接受请求，但尚未处理
        301  Moved Permanently  请求的网页已永久移动到新位置。
        302 Found       临时性重定向。
        303 See Other   临时性重定向，且总是使用 GET 请求新的 URI。
        304  Not Modified 自从上次请求后，请求的网页未修改过。

        400 Bad Request  服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。
        401 Unauthorized 请求未授权。
        403 Forbidden   禁止访问。
        404 Not Found   找不到如何与 URI 相匹配的资源。

        500 Internal Server Error  最常见的服务器端错误。
        503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。
    ]

2. 네트워크 - 기타

1. URL 입력부터 페이지 로딩 완료 및 페이지 표시까지의 과정에서 어떤 일이 발생하나요? (과정은 자세할수록 좋습니다)
URL 입력부터 페이지 로딩 완료, 페이지 표시까지의 과정에서 일어나는 일

2. 7레이어 모델의 7레이어에 대해 이야기해보겠습니다. 네트워크 계층

  • 애플리케이션 계층: 애플리케이션 계층, 프리젠테이션 계층, 세션 계층(위에서 아래로)(HTTP, FTP, SMTP, DNS)

  • 전송 계층(TCP 및 UDP)

  • 네트워크 계층(IP)

  • 물리적 및 데이터 링크 계층(이더넷)

  • 각 계층의 기능은 다음과 같습니다.

  • 물리적 계층: 매체를 통해 비트를 전송하고 기계적 및 전기적 사양을 결정합니다(비트 ) 데이터 링크 계층: 비트가 프레임으로 조립되어 지점 간 전송(Frame)

    • 네트워크 계층: 소스에서 대상까지 데이터 패킷의 전송 및 인터넷 상호 연결을 담당(Packet)

    • Transport 계층: 엔드 투 엔드 안정적인 메시지 전달 및 오류 복구 제공(세그먼트)

    • 세션 계층: 세션 설정, 관리 및 종료(Session Protocol Data Unit SPDU)

    • 프레젠테이션 계층: 데이터 변환, 암호화 및 압축 (프로토콜 데이터 단위 PPDU를 나타냄)

    • 애플리케이션 계층: OSI 환경에 대한 접근을 허용하는 수단(Application Protocol Data Unit APDU)

3. 304 캐싱의 원리

  • 서버가 생성 ETag를 먼저 지정하고 서버는 나중에 이를 수행할 수 있습니다. 이를 사용하여 페이지가 수정되었는지 확인합니다. 기본적으로 클라이언트는 이 토큰을 서버에 다시 전송하여 해당 (클라이언트) 캐시를 확인하도록 요청합니다. 304는 이를 사용하여 파일이 수정되지 않았으며 콘텐츠를 반환하지 않음을 나타냅니다. 브라우저는 상태 코드를 받은 후 브라우저의 캐시된 파일

  • 을 사용하여 페이지(A)를 요청합니다. 서버는 페이지 A를 반환하고 A에 ETag를 추가합니다. 클라이언트는 페이지를 렌더링하고 ETag와 함께 페이지를 캐시합니다. 클라이언트는 페이지 A를 다시 요청하고 마지막 요청 중에 서버가 반환한 ETag와 함께 이를 서버에 전달합니다. 서버는 ETag를 확인하고 마지막 클라이언트 요청 이후 페이지가 수정되지 않았음을 확인하고 응답 304(수정되지 않음)와 빈 응답 본문을 직접 반환합니다.

  • 자세히 알아보기 - 서버 캐시 찾아보기

    • 이 기사의 사례를 읽고 나면 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

추천 도서:

Oday의 권한 상승 및 쇼핑몰 서버의 루트 권한을 일괄적으로 획득하는 과정에 대한 자세한 설명

HTML에서 JS 메서드 사용 요약

위 내용은 프런트 엔드, HTT, 컴퓨터 및 네트워크의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명：
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
이전 기사：Oday가 권한을 승격하고 쇼핑몰 서버의 루트 권한을 일괄적으로 획득하는 단계에 대한 자세한 설명다음 기사：Oday가 권한을 승격하고 쇼핑몰 서버의 루트 권한을 일괄적으로 획득하는 단계에 대한 자세한 설명

관련 기사

더보기