면접관이 질문했습니다. TCP 연결은 몇 개의 HTTP 요청을 보낼 수 있습니까?
다음과 같은 고전적인 인터뷰 질문이 있었습니다. 브라우저에 URL을 입력하고 페이지가 표시되는 과정에서 어떤 일이 발생합니까?
준비한 대부분의 학생들이 대답할 수 있다고 생각하지만 계속해서 질문한다면 수신된 HTML에 수십 개의 이미지 태그가 포함되어 있다면 어떤 방식으로, 어떤 순서로, 몇 개의 연결이 설정되는지, 어떤 프로토콜이 사용되는지 다운로드한 것은 어떻습니까?
이 문제를 이해하려면 먼저 다음 다섯 가지 질문을 해결해야 합니다.
1. 서버와 TCP 연결을 설정한 후 HTTP 요청이 완료된 후 최신 브라우저의 연결이 끊어 집니까? 어떤 상황에서 연결이 끊어지나요?
2. 하나의 TCP 연결은 몇 개의 HTTP 요청에 대응할 수 있나요?
3. TCP 연결에서 HTTP 요청을 함께 보낼 수 있나요?(예: 요청 3개를 함께 보내고 응답 3개를 함께 수신)
4. 때때로 페이지를 새로 고칠 때 SSL 연결을 다시 설정할 필요가 없는 이유는 무엇입니까?
5. 브라우저에는 동일한 호스트가 설정하는 TCP 연결 수에 제한이 있나요?
첫 번째 질문
최신 브라우저는 서버와 TCP 연결을 설정한 후 HTTP 요청이 완료된 후 연결이 끊어지나요? 어떤 상황에서 연결이 끊어지나요?
HTTP/1.0에서는 서버가 HTTP 응답을 보낸 후 TCP 연결을 끊습니다. 그러나 각 요청은 TCP 연결을 다시 설정하고 연결을 끊기 때문에 비용이 너무 많이 듭니다. 따라서 표준에 설정되어 있지 않더라도 일부 서버에서는 Connection: keep-alive 헤더를 지원합니다. 즉, 이 HTTP 요청을 완료한 후에는 HTTP 요청에 사용되는 TCP 연결을 끊지 마십시오. 이것의 장점은 연결을 재사용할 수 있고 나중에 HTTP 요청을 보낼 때 TCP 연결을 다시 설정할 필요가 없다는 것입니다. 연결이 유지되면 SSL의 오버헤드도 피할 수 있습니다. 짧은 시간 안에 www.github을 두 번 방문했습니다. .com의 시간 통계:
첫 번째 방문에는 초기 연결 및 SSL 오버헤드가 있습니다.
초기 연결 및 SSL 오버헤드가 사라졌음을 나타냅니다. 동일한 TCP 연결이 사용됩니다.
지속적 연결: TCP가 유지되므로 연결의 이점이 너무 많습니다. HTTP/1.1은 연결 헤더를 표준에 작성했으며 요청에 연결: 닫기가 표시되지 않는 한 기본적으로 지속적인 연결을 활성화합니다. 브라우저와 서버 간의 TCP 연결은 일정 시간 동안 유지되며 요청이 완료되면 연결이 끊어집니다.
첫 번째 질문에 대한 대답은 다음과 같습니다. 기본적으로 TCP 연결이 설정되고 연결이 끊어지지 않습니다. 요청 헤더에 Connection: close를 선언하면 요청이 완료된 후 연결이 닫힙니다.
두 번째 질문
하나의 TCP 연결은 몇 개의 HTTP 요청에 대응할 수 있나요?
첫 번째 질문을 이해하면 이 질문에는 이미 답변이 있습니다. 연결이 유지되면 TCP 연결은 여러 HTTP 요청을 보낼 수 있습니다.
세 번째 질문
TCP 연결에서 HTTP 요청을 함께 보낼 수 있나요?(예를 들어 세 개의 요청을 함께 보내고 세 개의 응답을 함께 수신하는 경우)?
HTTP/1.1 문제가 있습니다. 단일 TCP 연결은 동시에 하나의 요청만 처리할 수 있습니다. 즉, 두 요청의 수명 주기는 처음부터 끝까지 동일할 수 없습니다. TCP 연결은 겹칠 수 없습니다.
HTTP/1.1 사양에서는 이 문제를 해결하기 위해 파이프라이닝을 지정하고 있지만 브라우저에서는 이 기능이 기본적으로 꺼져 있습니다.
먼저 파이프라이닝이 무엇인지 살펴보겠습니다. RFC 2616은 다음과 같이 규정합니다.
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一个支持持久连接的客户端可以在一个连接中发送多个请求(不需要等待任意请求的响应)。收到请求的服务器必须按照请求收到的顺序发送响应。
표준이 이렇게 설정되는 이유는 대략적으로 한 가지 이유를 추측할 수 있습니다. HTTP/1.1은 텍스트 프로토콜이므로 반환되는 콘텐츠는 다음과 같습니다. 어떤 요청이 전송되는지 구별할 수 없으므로 순서가 일관되어야 합니다. 예를 들어, 서버에 두 개의 요청(GET/query?q=A 및 GET/query?q=B)을 보내고 서버가 두 개의 결과를 반환하는 경우 브라우저는 응답이 어떤 요청에 해당하는지 확인할 방법이 없습니다. 응답 결과.
파이프라이닝 이 아이디어는 좋아 보이지만 실제로는 많은 문제가 있습니다.
일부 프록시 서버는 HTTP 파이프라이닝을 올바르게 처리할 수 없습니다.
올바른 파이프라인 구현은 복잡합니다.
헤드 오브 라인 차단: TCP 연결을 설정한 후 이 연결 중에 클라이언트가 서버에 여러 요청을 지속적으로 보낸다고 가정합니다. 표준에 따르면 서버는 요청이 수신된 순서대로 결과를 반환해야 합니다. 서버가 첫 번째 요청을 처리하는 데 많은 시간을 소비한다고 가정하면 모든 후속 요청은 응답하기 전에 첫 번째 요청이 완료될 때까지 기다려야 합니다. .
따라서 최신 브라우저는 기본적으로 HTTP 파이프라이닝을 활성화하지 않습니다.
그러나 HTTP2는 TCP 연결에서 여러 HTTP 요청을 동시에 완료할 수 있는 멀티플렉싱 기능을 제공합니다. 멀티플렉싱이 얼마나 정확하게 구현되는지는 또 다른 질문입니다. HTTP2 사용의 효과를 살펴볼 수 있습니다.
녹색은 요청 시작부터 반환 요청까지의 대기 시간이고 파란색은 응답 다운로드 시간이며 모두 동일한 연결에서 병렬로 완료되는 것을 볼 수 있습니다
그래서 이 질문에도 답이 있습니다 : HTTP/1.1에는 동시에 여러 요청을 보낼 수 있는 Pipelining 기술이 있지만, 기본적으로 브라우저가 꺼져 있기 때문에 이는 불가능하다고 볼 수 있습니다. HTTP2의 멀티플렉싱 기능으로 인해 동일한 TCP 연결에서 여러 HTTP 요청을 병렬로 처리할 수 있습니다.
그렇다면 HTTP/1.1 시대에 브라우저는 어떻게 페이지 로딩 효율성을 향상시킬 수 있을까요? 두 가지 주요 사항이 있습니다.
서버와 설정된 TCP 연결을 유지하고 동일한 연결에서 여러 요청을 순차적으로 처리합니다.
서버와 다중 TCP 연결을 설정합니다.
네 번째 질문
때때로 페이지를 새로 고칠 때 SSL 연결을 다시 설정할 필요가 없는 이유는 무엇입니까?
첫 번째 질문에 대한 토론에서 이미 답변을 찾을 수 있습니다. TCP 연결은 때때로 브라우저와 서버에 의해 일정 기간 유지됩니다. TCP는 재설정할 필요가 없으며 SSL은 자연스럽게 이전 TCP를 사용하게 됩니다.
다섯 번째 질문
브라우저에는 동일한 호스트가 설정한 TCP 연결 수에 제한이 있나요?
당시에는 멀티플렉싱이 없었다고 가정해 보겠습니다. 수십 개의 이미지가 포함된 웹페이지를 받으면 브라우저는 어떻게 해야 할까요? 순차 다운로드를 위해 TCP 연결을 여는 것은 확실히 불가능합니다. 그렇지 않으면 사용자는 반드시 기다려야 합니다. 그러나 HTTP 요청을 보내기 위해 각 사진에 대해 TCP 연결이 열리면 컴퓨터나 서버가 이를 감당하지 못할 수도 있습니다. 1,000장의 사진이 있으면 1000개의 TCP 연결을 열 수 없으며, 컴퓨터가 NAT에 동의하더라도 동의하지 않을 수 있습니다.
그래서 대답은: 그렇습니다. Chrome은 동일한 호스트에 최대 6개의 TCP 연결을 허용합니다. 브라우저마다 약간의 차이가 있습니다.
developers.google.com/web/tools/ch...
다시 원래 질문으로 돌아가서, 수신된 HTML에 수십 개의 이미지 태그가 포함되어 있다면 이러한 이미지는 어떤 방식으로, 어떤 순서로 포함되어 있나요? 연결이 설정되었으며 이를 다운로드하는 데 어떤 프로토콜이 사용되었습니까?
이미지가 모두 HTTPS 연결이고 동일한 도메인 이름 아래에 있는 경우 브라우저는 SSL 핸드셰이크 후 서버와 HTTP2를 사용할 수 있는지 논의하고, 그렇다면 멀티플렉싱 기능을 사용하여 이 연결에서 멀티플렉싱을 수행합니다. 그러나 이 도메인 이름에 나열된 모든 리소스가 반드시 TCP 연결을 사용하여 얻어지는 것은 아니지만 멀티플렉싱이 사용될 가능성은 확실합니다.
HTTP2를 사용할 수 없다면 어떻게 해야 할까요? 또는 HTTPS를 사용할 수 없습니다(실제로는 HTTPS에 HTTP2가 구현되어 있으므로 HTTP/1.1만 사용할 수 있습니다). 브라우저는 호스트에서 여러 TCP 연결을 설정합니다. 연결 수의 최대 제한은 브라우저 설정에 따라 다릅니다. 모든 연결이 요청을 보내는 경우 브라우저는 이러한 연결을 사용하여 요청을 보냅니다. 그런 다음 다른 요청을 기다려야 합니다. #
위 내용은 면접관이 질문했습니다. TCP 연결은 몇 개의 HTTP 요청을 보낼 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











HTTP 상태 코드 520은 서버가 요청을 처리하는 동안 알 수 없는 오류가 발생하여 더 구체적인 정보를 제공할 수 없음을 의미합니다. 서버가 요청을 처리하는 동안 알 수 없는 오류가 발생했음을 나타내는 데 사용됩니다. 이는 서버 구성 문제, 네트워크 문제 또는 기타 알 수 없는 이유로 인해 발생할 수 있습니다. 이는 일반적으로 서버 구성 문제, 네트워크 문제, 서버 과부하 또는 코딩 오류로 인해 발생합니다. 상태 코드 520 오류가 발생하면 웹사이트 관리자나 기술 지원팀에 문의하여 자세한 정보와 지원을 받는 것이 가장 좋습니다.

win10에서 tcp/ip 프로토콜을 재설정하는 방법은 무엇입니까? 실제로 방법은 매우 간단합니다. 사용자는 명령 프롬프트를 직접 입력한 다음 Ctrl+Shift+Enter 키 조합을 눌러 작업을 수행하거나 재설정 명령을 직접 실행하여 설정해 보겠습니다. 사용자에게 Windows 10에서 TCP/IP 프로토콜 스택을 재설정하는 방법에 대한 자세한 소개를 제공합니다. Windows 10에서 tcp/ip 프로토콜 스택을 재설정하는 방법 1. 관리자 권한 1. 단축키 win+R을 사용하여 실행 창을 직접 연 다음 cmd를 입력하고 ctrl+shift+enter 키 조합을 길게 누릅니다. 2. 또는 시작 메뉴에서 명령 프롬프트를 직접 검색하고 마우스 오른쪽 버튼을 클릭할 수도 있습니다.

HTTP 상태 코드 403은 서버가 클라이언트의 요청을 거부했음을 의미합니다. http 상태 코드 403에 대한 해결 방법은 다음과 같습니다. 1. 서버에 인증이 필요한 경우 올바른 자격 증명이 제공되었는지 확인합니다. 2. 서버가 IP 주소를 제한한 경우 클라이언트의 IP 주소가 제한되어 있거나 블랙리스트에 없습니다. 3. 파일 권한 설정을 확인하십시오. 403 상태 코드가 파일 또는 디렉토리의 권한 설정과 관련되어 있으면 클라이언트가 해당 파일 또는 디렉토리에 액세스할 수 있는 권한이 있는지 확인하십시오. 등.

NginxProxyManager를 사용하여 HTTP에서 HTTPS로의 자동 점프를 구현하는 방법 인터넷이 발전하면서 점점 더 많은 웹사이트가 HTTPS 프로토콜을 사용하여 데이터 전송을 암호화하여 데이터 보안과 사용자 개인 정보 보호를 향상시키기 시작했습니다. HTTPS 프로토콜에는 SSL 인증서 지원이 필요하므로 HTTPS 프로토콜 배포 시 특정 기술 지원이 필요합니다. Nginx는 강력하고 일반적으로 사용되는 HTTP 서버 및 역방향 프록시 서버이며 NginxProxy

HTTP 301 상태 코드의 의미 이해: 웹 페이지 리디렉션의 일반적인 응용 시나리오 인터넷의 급속한 발전으로 인해 사람들은 웹 페이지 상호 작용에 대한 요구 사항이 점점 더 높아지고 있습니다. 웹 디자인 분야에서 웹 페이지 리디렉션은 HTTP 301 상태 코드를 통해 구현되는 일반적이고 중요한 기술입니다. 이 기사에서는 HTTP 301 상태 코드의 의미와 웹 페이지 리디렉션의 일반적인 응용 프로그램 시나리오를 살펴봅니다. HTTP301 상태 코드는 영구 리디렉션(PermanentRedirect)을 나타냅니다. 서버가 클라이언트의 정보를 받을 때

http.PostForm 함수를 사용하여 양식 데이터와 함께 POST 요청을 보낼 수 있습니다. Go 언어의 http 패키지에서는 http.PostForm 함수를 사용하여 양식 데이터와 함께 POST 요청을 보낼 수 있습니다. http.PostForm 함수의 프로토타입은 다음과 같습니다: funcPostForm(urlstring,dataurl.Values)(resp*http.Response,errerror)where, u

빠른 적용: PHP의 실제 개발 사례 분석 여러 파일의 비동기 HTTP 다운로드 인터넷의 발전으로 파일 다운로드 기능은 많은 웹 사이트와 응용 프로그램의 기본 요구 사항 중 하나가 되었습니다. 여러 파일을 동시에 다운로드해야 하는 시나리오의 경우 기존 동기 다운로드 방법은 비효율적이고 시간이 많이 걸리는 경우가 많습니다. 이러한 이유로 PHP를 사용하여 HTTP를 통해 여러 파일을 비동기적으로 다운로드하는 것이 점점 더 일반적인 솔루션이 되었습니다. 본 글에서는 실제 개발 사례를 통해 PHP 비동기 HTTP를 활용하는 방법을 자세히 분석해 보겠습니다.

HTTP 상태 코드 200: 성공적인 응답의 의미와 목적 탐색 HTTP 상태 코드는 서버 응답 상태를 나타내는 데 사용되는 숫자 코드입니다. 그 중 상태 코드 200은 요청이 서버에 의해 성공적으로 처리되었음을 나타냅니다. 이 기사에서는 HTTP 상태 코드 200의 구체적인 의미와 사용법을 살펴보겠습니다. 먼저 HTTP 상태 코드의 분류를 이해해 보겠습니다. 상태 코드는 1xx, 2xx, 3xx, 4xx 및 5xx의 다섯 가지 범주로 나뉩니다. 그 중 2xx는 성공적인 응답을 나타냅니다. 그리고 200은 2xx에서 가장 일반적인 상태 코드입니다.
