HTTP 프로토콜 소개 및 심층적인 이해

실제 작업 시나리오에서 접한 http 프로토콜과 관련된 일부 내용에 대한 나의 이해를 요약합니다.

요청 및 응답

요청 형식

예: GET /api/index.json HTTP/1.1

; 사용자 -에이전트: Mozilla/4.0;……

<빈 줄>

[] 예: id=1×tamp=xxxxxx

　응답 형식

: HTTP/1.1 200 OK

예: Content-Type: application/json;......

[] 예: { "id":1,"username": "testuser"}

　Status Code

　약 60개의 http 상태 코드가 있습니다. 여기에는 일상적인 애플리케이션에서 다소 발생하는 비정상적인 상황에서 생성되는 몇 가지 일반적인 상태 코드를 주로 기록합니다. . 문제를 이해하고 식별하는 데 도움이 됩니다.

206 - 중단점 다운로드 중에 사용됩니다. 클라이언트가 콘텐츠의 일부를 요청했고 서버가 콘텐츠의 이 부분을 성공적으로 반환했습니다. 이 상태는 현재 사용됩니다.

301 - 영구 점프, 원래 주소가 더 이상 존재하지 않으며 URL이 다른 주소를 가리킵니다. 이는 주로 검색 엔진과 관련되어 있으며 크롤러의 검색 동작에 영향을 미칩니다.

302 - 임시 점프, 서버는 클라이언트에 새 URL을 반환하고 클라이언트는 계속해서 이 URL에 액세스하여 콘텐츠를 얻을 수 있습니다.

304 - 리소스는 변경되지 않았습니다. 클라이언트는 정적 콘텐츠 액세스에 일반적으로 사용되는 로컬로 캐시된 콘텐츠를 사용할 수 있습니다.

413 - 요청 엔터티가 너무 큽니다. 일반적인 상황은 대용량 파일을 업로드하는 것이지만 서버(예: nginx) 제한을 초과하는 것입니다. 또는 요청 헤더 또는 요청 본문이 백엔드 서버(예: tomcat)의 설정을 초과합니다(예: 현재 도메인 이름 아래에 쿠키가 너무 많아 요청 헤더 제한을 초과함)

416 - 관련이 있습니다. 중단점 재개 및 클라이언트 요청 범위가 서버의 파일 크기를 초과합니다.

500 - 서버 내부 오류로 인해 정상적인 결과를 반환할 수 없습니다. 예를 들어 가장 일반적인 애플리케이션에서는 처리되지 않는 널 포인터 예외가 발생합니다.

502 - 게이트웨이 오류. 일반적인 상황은 역방향 프록시 백엔드 서버(예: Resin 또는 Tomcat)가 시작되지 않는 것입니다.

503 - 서비스를 이용할 수 없습니다. 예를 들어 서버 부하가 너무 높거나 서버가 서비스를 중지했습니다.

504 - 게이트웨이 시간 초과. 예를 들어 요청 기간이 서버의 응답 시간 제한을 초과합니다.

　Headers

　http 헤더는 요청 헤더와 응답 헤더의 두 가지 범주로 나뉩니다. 다음은 우리가 자주 사용하는 헤더입니다.

　1. 캐시 제어

　 인터넷 웹사이트 애플리케이션에서 캐시는 거의 모든 곳에 있습니다. http 기반 서비스에서는 클라이언트에서 자주 변경되지 않는 일부 콘텐츠도 제어할 수 있습니다. 결국 캐시된 콘텐츠를 여러 번 방문할 때 재사용할 수 있어 액세스 속도가 빨라지고 사용자 경험이 향상됩니다. http 프로토콜은 캐시 제어를 위한 일부 http 헤더를 규정합니다.

Cache-Control(HTTP/1.1)/Pragma(HTTP/1.0): 클라이언트가 캐시하는지 여부와 캐시가 지속되는 기간을 나타냅니다. 기본값은 비공개입니다. 이는 콘텐츠가 사용자의 비공개 공간에 캐시된다는 의미입니다. 예: Cache-Control: max-age=86400, must-revalidate. 이는 요청된 리소스가 하루 동안 캐시되고(max-age 단위는 초, 상대 시간) 만료 후 다시 확인해야 함을 클라이언트에 알려줍니다.

Expires: 클라이언트(강제 새로 고침이 필요하지 않은 경우)가 서버에 요청을 보내지 않고 로컬 캐시를 직접 읽을 수 있는 기간을 지정합니다.

참고:

우선순위: Cache-Control > Expires;

자세한 매개변수 설명: http://condor.depaul.edu/dmumaugh/readings/handouts/SE435/HTTP/node24.html

다른 브라우저 다른 동작 (새로 고침, 뒤로, 주소 표시줄에 입력 등) 구현에 차이가 있을 수 있습니다.

Last-Modified/If-Modified-Since: Last-Modified는 서버가 클라이언트에 반환한 리소스의 마지막 수정 타임스탬프입니다. 따라서 클라이언트는 다음 요청(예: 강제 새로 고침)을 수행할 때 If-Modified-Since 매개변수를 가져와 리소스가 업데이트되었는지 확인합니다. 업데이트가 없으면 서버는 304 상태 코드를 반환합니다. 클라이언트는 로컬로 캐시된 리소스를 직접 가져옵니다. 이때는 요청 오버헤드만 있고 네트워크 전송 오버헤드는 없습니다. 참고: 타임스탬프는 그리니치 표준시(GMT)여야 합니다. 예: Last-Modified:Sat, 19 Oct 2013 09:20:15 GMT

ETag/If-None-Match: ETag는 다음을 기반으로 하는 특정 알고리즘을 통해 생성됩니다. 파일 속성 리소스 식별자는 클라이언트가 요청한 리소스가 업데이트되었는지 여부를 확인하는 데에도 사용됩니다. 서버가 클라이언트에 ETag 값을 반환하면 다음에 클라이언트가 이를 요청할 때 If-None-Match 매개변수를 가져와 리소스가 업데이트되었는지 확인합니다. 업데이트되지 않은 경우 304 상태 코드가 반환됩니다. . (기본적으로 Last-Modified와 효과는 동일합니다.)

참고:

ETag를 계산해야 하는데, 이는 컴퓨팅 리소스가 부족한 서버에 대한 소비이므로 일부 웹사이트에서는 ETag를 직접 사용하지 않습니다.

서버가 로드 밸런서 뒤에 있는 경우 동일한 리소스에 대한 요청이 다른 백엔드 시스템에 분산될 수 있습니다. ETag 계산은 파일 속성에 따라 달라지므로 다른 시스템에 있는 동일한 내용을 가진 파일은 다른 ETag를 생성할 수 있습니다. 내용이 변경되지 않은 원본 파일은 ETag 확인을 통과하지 못했습니다. 여기에는 두 가지 해결책이 있습니다. 하나는 파일 콘텐츠의 md5 값을 직접 계산하는 것과 같이 etag 계산이 로컬 시스템에 의존하지 않는다는 것입니다. 다른 하나는 로드 시 동일한 URL 요청을 동일한 백엔드 시스템에 배포하는 것입니다. 밸런서.

실제 비즈니스 시나리오에서 http 캐싱은 다음과 같이 매우 유용하게 사용됩니다.

로고, 광고 이미지 등과 같이 클라이언트가 자주 액세스해야 하는 일부 정적 파일과 같은 클라이언트 리소스를 최대한 활용합니다. ., 완전히 클라이언트에서 로컬로 캐시될 수 있습니다. 이를 통해 네트워크 요청을 줄이고 클라이언트 표시 속도를 높이며 서버 요청에 대한 부담을 줄일 수 있습니다.

뉴스, 블로그 등과 같은 일부 정적 콘텐츠가 검색 엔진 크롤러에 의해 크롤링될 때 캐시 매개변수를 제어하여 크롤러의 크롤링 빈도를 줄이고 불필요한 리소스 낭비를 줄일 수 있습니다.

정적 리소스가 CDN을 사용하는 경우 http 캐시를 설정하면 CDN 노드에 파일을 저장할 수 있으므로 CDN이 원본으로 반환되는 횟수가 줄어들고 네트워크 지연 및 원본 서버 부담이 줄어듭니다.

　　2. 중단점 요청

Accept-Ranges: 서버가 중단점 다운로드를 지원하면 이 응답 헤더를 클라이언트에 반환합니다. 클라이언트가 이를 알게 되면 중단점 요청을 보낼 수 있습니다.

Content-Length: 현재 요청에서 반환된 데이터의 양을 클라이언트에게 알려주는 응답 정보의 길이입니다. 여기에서 헤드 메소드를 사용하여 요청을 제출할 때 특정 데이터가 반환되지 않지만 Content-Length는 전체 데이터의 크기를 반환한다는 점에 유의해야 합니다.

Range/Content-Range: 클라이언트는 요청할 때 Range라는 헤더를 제출하여 서버에 요청하려는 데이터 부분을 알려줍니다. 예: Range: bytes=0-1023은 0~1023바이트를 요청한다는 의미입니다. 그런 다음 서버는 이 1024바이트의 내용을 클라이언트에 반환하고 Content-Range가 응답 헤더에 포함됩니다. 즉, Content-Range: 바이트 0-1023/4096, 이 4096은 전체 파일 크기입니다. 클라이언트의 다음 요청은 1024번째 바이트부터 시작할 수 있습니다. 범위: bytes=1024-xxxx

　　3. Encoding

Accept-Encoding/Content-Encoding: 전자는 클라이언트가 지원하는 메시지 인코딩 유형입니다. 기본값은 ID이며 선택 값에는 gzip, 압축 등이 포함됩니다. 후자는 서버 측 응답 정보의 콘텐츠 인코딩 유형으로 압축이 일반적으로 사용됩니다. 압축의 이점은 분명합니다. 서버 측 압축으로 인한 CPU 소비와 비교하면 네트워크 전송 비용을 크게 줄일 수 있습니다. 일반적인 형식: Content-Encoding: gzip, deflate, 압축 일반적으로 html, js, css, xml 및 json과 같은 응답 결과를 압축하여 전송할 수 있습니다.

Transfer-Encoding: 응답 헤더. 응답 메시지의 전송 인코딩 유형은 네트워크 전송 형식을 지정합니다. 일반적으로 전송-인코딩: 청크 형식입니다. 서버가 동적 콘텐츠를 생성하고 응답 정보의 구체적인 길이를 알 수 없는 경우 이 지정된 블록을 통해 전송하고 처리한 만큼의 데이터를 반환할 수 있으므로 데이터가 준비될 때까지 기다렸다가 반환할 필요가 없습니다. 한꺼번에. 위의 콘텐츠 인코딩(gzip 등)과 결합하여 블록 단위로 압축하여 전송할 수 있습니다. 또한 이 인코딩을 사용하여 전송할 때 콘텐츠가 완전히 생성되지 않았기 때문에 Content-Length를 볼 수 없다는 점에 유의하시기 바랍니다.

　4. 기타

X-Forward-For: 요청 헤더입니다. 특히 프록시(정방향 또는 역방향)를 통해 서버에 액세스하거나 서버가 로드 밸런싱 장치 뒤에 있는 경우 사용자의 실제 IP를 식별하는 데 사용됩니다. 형식: X-forward-For: client,proxy1,proxy2,...가장 왼쪽이 클라이언트에 가장 가까운 IP입니다.

User-Agent: 요청 헤더. 서버가 클라이언트의 기본 정보를 식별하는 데 사용하는 요청 헤더입니다. 일반적으로 이는 검색 크롤러를 식별할 때 유용하며 일부 클라이언트 통계를 수행하는 데에도 사용될 수 있습니다.

Referer: 요청 헤더. 클라이언트가 서버에 액세스할 때 이 Referer는 요청이 연결된 웹사이트 등 요청 소스를 지정합니다. 또한, 또 다른 중요한 용도는 리소스 핫링크 방지가 필요한 시나리오에서 불법적인 요청 소스를 필터링하는 것입니다(그러나 이 참조자는 클라이언트에 의해 위조될 수 있습니다).

Location: 응답 헤더. 이 Location 헤더는 301/302 상태 코드의 응답 헤더에 포함되어 클라이언트가 필요한 리소스에 액세스하기 위해 새 주소를 사용하도록 지시합니다.

Connection: 요청/응답 헤더. http/1.1에서는 클라이언트와 서버가 기본적으로 연결을 유지합니다. 즉, 어느 쪽이든 연결 유지를 원하지 않는 경우 이 값을 다음과 같이 설정할 수 있습니다. close .기본적으로 클라이언트와 서버는 긴 연결을 유지하므로 클라이언트는 이 연결을 사용하여 여러 http 요청을 보낼 수 있으므로 빈번한 연결 생성으로 인한 소비를 줄일 수 있습니다. 이 매개변수의 경우 연결 유지 시간 및 서버 커널(tcp용)의 일부 네트워크 매개변수 설정과 같이 서버 측에서 추가 설정이 필요할 수 있습니다.

　세션 및 쿠키

　http 요청은 상태 비저장 요청이지만 인터넷 애플리케이션에서는 사용자 로그인 상태를 기록하기 위한 사용자 인증, 선택한 제품을 기억하기 위한 장바구니 애플리케이션과 같은 일부 대화형 작업을 완료하기 위해 사용자 상태 정보를 식별해야 하는 경우가 많습니다. 사용자, 광고 전달 애플리케이션은 사용자의 과거 탐색 행동 등을 기록해야 합니다. 세션과 쿠키가 여기에서 사용됩니다.

session: http 요청-응답 프로세스 중 클라이언트와 서버 간의 상호 작용 상태를 나타냅니다. 이 정보는 메모리, 데이터베이스 등 서버 측에 저장됩니다. 각 세션에는 서버에서 생성된 고유 식별자가 있으므로 클라이언트가 다음 요청 시 이 식별자를 가져와 서버가 클라이언트 상태를 쉽게 확인할 수 있도록 해야 합니다.

세션에 대한 클라이언트 지원:

쿠키를 통해 세션 ID를 저장하고 요청 시 서버로 보냅니다.

URL 매개변수에 세션 ID를 전달하여 서버와 통신합니다.

양식의 숨겨진 필드에 세션 ID를 전달하여 서버와 통신합니다.

세션 공유 문제:

분산 애플리케이션에서 당사의 http 서버는 일반적으로 역방향 프록시 또는 로드 밸런싱 장치 뒤에 설치되므로 세션 공유 문제에 직면하게 됩니다. 즉, 동일한 사용자의 여러 요청이 여러 다른 컴퓨터에 배포될 수 있습니다. 세션을 컴퓨터의 로컬 메모리에 저장하면 여러 컴퓨터 간에 사용자 세션을 공유할 수 없습니다. 일반적으로 우리는 이 문제를 두 가지 방법으로 해결할 수 있습니다:

세션을 분산 메모리(예: memcached) 또는 중앙 집중식 저장소(예: 데이터베이스)에 저장합니다.

동일한 사용자의 요청을 역방향 프록시 또는 로드 밸런싱 장치의 동일한 시스템에 배포합니다(여기서는 시스템이 다운된 후 요청 재분배 문제를 처리해야 합니다).

쿠키: 클라이언트에서 상태 저장 정보를 유지합니다. 각 쿠키 콘텐츠는 특정 도메인(도메인) 및 경로(경로)에 속합니다. 보안상의 이유로 다른 도메인이나 경로의 쿠키는 공유할 수 없습니다.

세션 쿠키: 만료 시간이 지정되지 않으며 메모리에 저장되며 브라우저가 닫힌 후 만료됩니다.

영구 쿠키: 만료 시간을 지정하고 브라우저에 로컬로 저장됩니다.

자세한 내용은 http://en.wikipedia.org/wiki/HTTP_cookie

를 참조하세요. 쿠키에는 보안 문제가 있다는 점에 유의하세요.

여기서는 직장에서 접한 http 프로토콜과 관련된 일부 내용에 대해 제가 이해한 내용을 요약했습니다. http 프로토콜에는 아직 탐구해야 할 부분이 많고, http에 대한 이해도 계속해서 탐구해야 합니다. 프로토콜은 우리에게 줄 것입니다. 애플리케이션의 개발은 큰 편리함을 가져다줍니다.

마지막으로 두 가지 NB http 디버깅 도구를 추천합니다. fiddler(windows)와 charles(mac)에는 http 프록시 기능이 있습니다. 브라우저 기반이 아닌 http 애플리케이션(예: 모바일 앱)의 경우 이 두 도구를 사용하여 수행할 수 있습니다. http 요청을 모니터링합니다.

위 내용은 HTTP 프로토콜 소개 및 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!