직렬 연결
HTTP/0.9 및 초기 HTTP/1.0 프로토콜은 HTTP 요청 처리를 직렬화합니다. 페이지에 3개의 스타일 파일이 포함되어 있고 모두 동일한 프로토콜, 도메인 이름 및 포트에 속한다고 가정합니다. 그런 다음 브라우저는 총 4개의 요청을 시작해야 하며 매번 하나의 TCP 채널만 열 수 있습니다. 요청된 리소스가 다운로드되면 연결이 즉시 끊어지고 대기열의 다음 요청을 처리하기 위해 새 연결이 열립니다. . 페이지 리소스의 크기와 수가 계속해서 증가하면 네트워크 대기 시간도 계속해서 누적됩니다. 사용자는 너무 오래 기다리면 빈 화면이 나타나고 인내심을 잃게 됩니다.
병렬 연결
네트워크 처리량을 향상시키기 위해 향상된 HTTP 프로토콜을 통해 클라이언트는 동시에 여러 TCP 연결을 열고 여러 리소스를 병렬로 요청하며 대역폭을 최대한 활용할 수 있습니다. . 일반적으로 각 연결 사이에는 일정한 지연이 있지만 요청의 전송 시간이 겹치고 전체 지연은 직렬 연결보다 훨씬 낮습니다. 각 연결이 시스템 리소스를 소비하고 서버가 많은 수의 동시 사용자 요청을 처리해야 한다는 점을 고려하여 브라우저는 동시 요청 수에 특정 제한을 설정합니다. RFC가 특정 제한을 지정하지 않더라도 각 브라우저 제조업체에는 자체 표준이 있습니다.
IE 7: 2
IE 8/9: 6
IE 10: 8
IE 11: 13
Firefox: 6
Chrome: 6
Safari: 6
Opera: 6
iOS WebView: 6
Android WebView: 6
지속적인 연결(긴 연결)
초기 HTTP 프로토콜은 각 요청에 대해 독립적인 TCP 연결을 사용했으며 이는 의심의 여지 없이 증가합니다. TCP의 연결 설정 오버헤드, 정체 제어 오버헤드, 연결 해제 오버헤드는 모두 향상된 HTTP/1.0과 HTTP/1.1(기본값)을 지원합니다. 요청이 완료되면 연결이 즉시 끊어지지 않지만, 다가오는 HTTP 요청을 빠르게 처리하고 클라이언트 하트비트 감지에 실패하거나 서버 연결 시간이 초과될 때까지 동일한 TCP 채널을 재사용하기 위해 일정 시간 동안 연결이 유지됩니다. . 이 기능은 HTTP 헤더 Connection: keep-alive를 통해 활성화할 수 있습니다. 클라이언트는 연결을 적극적으로 종료하기 위해 Connection: close를 보낼 수도 있습니다. 따라서 병렬 연결과 영구 연결의 두 가지 최적화가 서로를 보완한다는 것을 알 수 있습니다. 병렬 연결을 사용하면 첫 번째 로딩 페이지가 동시에 여러 TCP 연결을 열 수 있는 반면, 영구 연결은 후속 요청이 열린 TCP 연결을 재사용하도록 보장합니다. 현대 웹 페이지의 일반적인 메커니즘이기도 합니다.
파이프라인 연결
지속적 연결을 사용하면 연결을 재사용하여 여러 요청을 완료할 수 있지만 FIFO 대기열 순서를 충족해야 하며 이전 요청이 서버에 성공적으로 도달하고 성공적으로 처리되었는지 확인해야 합니다. 서버가 수신한 경우 반환된 첫 번째 바이트만 대기열의 다음 요청을 시작할 수 있습니다. HTTP 파이프를 사용하면 클라이언트가 응답을 기다릴 필요 없이 동일한 TCP 채널 내에서 연속적으로 여러 요청을 시작할 수 있으므로 왕복 대기 시간 차이가 사라집니다. 그러나 실제로는 HTTP/1.x 프로토콜의 한계로 인해 하나의 링크(IO 다중화)에 인터리브되어 데이터가 도착하는 것이 허용되지 않습니다. 클라이언트와 서버가 동시에 HTML 요청과 여러 CSS 요청을 보내는 상황을 상상해 보세요. 서버는 모든 요청을 병렬로 처리하고 모든 CSS 요청이 처리되어 버퍼 큐에 추가되면 HTML 요청 처리 중에 발생하는 것을 발견합니다. 심각한 경우에는 버퍼 오버플로가 발생할 수도 있습니다. 이러한 상황을 헤드 오브 라인(head-of-line) 차단이라고 합니다. 따라서 이 솔루션은 HTTP/1.x 프로토콜에 채택되지 않았습니다.
헤드 오브 라인 차단은 HTTP의 고유한 개념이 아니라 캐시된 통신 네트워크 교환에서 흔히 발생하는 현상입니다.
요약
1. 브라우저는 동일한 프로토콜, 도메인 이름 및 포트에 대해 개방형 TCP 연결을 허용합니다. 동시에 일반적으로 상한은 6입니다.
2. 동일한 TCP 연결은 여러 HTTP 요청을 시작할 수 있지만 이전 요청의 첫 번째 바이트 응답이 클라이언트에 도달할 때까지 기다려야 합니다.
3. 대기열 헤드 차단 문제로 인해 클라이언트는 대기열의 모든 요청을 동시에 보낼 수 없습니다. 이 문제는 HTTP/2.0에서 해결되었습니다.
위 내용은 HTTP 프로토콜의 동시성 제한 및 HOL 차단 문제의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!