http 긴 연결과 짧은 연결의 원리에 대한 간략한 분석

1. HTTP 프로토콜과 TCP/IP 프로토콜의 관계

HTTP의 길고 짧은 연결은 본질적으로 TCP의 길고 짧은 연결입니다. HTTP는 전송 계층에서는 TCP 프로토콜을 사용하고 네트워크 계층에서는 IP 프로토콜을 사용하는 애플리케이션 계층 프로토콜입니다. IP 프로토콜은 주로 네트워크 라우팅 및 주소 지정 문제를 해결하고 TCP 프로토콜은 주로 IP 계층 위에 데이터 패킷을 안정적으로 전달하는 방법을 해결하여 네트워크의 다른 쪽 끝이 발신자가 보낸 모든 패킷을 수신하고 순서가 일치하도록 합니다. 보내는 순서. TCP는 신뢰성 있고 연결 지향적인 특성을 가지고 있습니다.

　2. HTTP 프로토콜이 Stateless라는 것을 이해하는 방법

　HTTP 프로토콜은 Stateless입니다. 즉, 프로토콜에는 트랜잭션 처리를 위한 메모리 용량이 없으며 서버는 상태를 알 수 없습니다. 클라이언트의. 즉, 서버에서 웹페이지를 여는 것과 이전에 이 서버에서 열었던 웹페이지 사이에는 연관성이 없습니다. HTTP는 상태 비저장 연결 지향 프로토콜입니다. 상태 비저장은 HTTP가 TCP 연결을 유지할 수 없다는 의미도 아니고 HTTP가 UDP 프로토콜(연결 없음)을 사용한다는 의미도 아닙니다.

　3. 긴 연결과 짧은 연결이 무엇인가요?

HTTP/1.0에서는 기본적으로 짧은 연결이 사용됩니다. 즉, 브라우저와 서버가 HTTP 작업을 수행할 때마다 연결이 설정되지만 작업이 완료되면 연결이 중단됩니다. 클라이언트 브라우저에서 액세스하는 HTML 또는 기타 유형의 웹 페이지에 JavaScript 파일, 이미지 파일, CSS 파일 등과 같은 다른 웹 리소스가 포함되어 있는 경우 브라우저가 이러한 웹 리소스를 만날 때마다 HTTP 세션이 생성됩니다.

하지만 HTTP/1.1부터는 연결 특성을 유지하기 위해 기본적으로 긴 연결을 사용합니다. 긴 연결을 사용하는 HTTP 프로토콜은 응답 헤더에 다음 코드 줄을 추가합니다:

Connection:keep-alive

긴 연결을 사용할 때 웹 페이지가 열릴 때 클라이언트는 클라이언트와 서버 간에 HTTP 데이터를 전송하는 데 사용되는 TCP 연결은 닫히지 않습니다. 클라이언트가 이 서버의 웹 페이지에 다시 액세스하면 설정된 연결을 계속 사용합니다. Keep-Alive는 연결을 영구적으로 유지하지 않습니다. 다른 서버 소프트웨어(예: Apache)에서 설정할 수 있는 보존 시간이 있습니다. 긴 연결을 구현하려면 클라이언트와 서버 모두 긴 연결을 지원해야 합니다.

HTTP 프로토콜의 긴 연결과 짧은 연결은 본질적으로 TCP 프로토콜의 긴 연결과 짧은 연결입니다.

　3.1 TCP 연결

TCP 프로토콜을 네트워크 통신에 사용하는 경우 실제 읽기 및 쓰기 작업 전에 서버와 클라이언트 간에 연결이 설정되어야 합니다. 연결이 완료되면 양측 모두 더 이상 필요하지 않을 때 연결을 해제할 수 있습니다. 연결 설정에는 세 번의 핸드셰이크가 필요하고 해제에는 네 번의 핸드셰이크가 필요하므로 각 연결 설정에는 리소스 소비와 시간 소비가 필요합니다

클래식 3방향 핸드셰이크 다이어그램:

클래식 4방향 핸드셰이크 종료 다이어그램:

3.2 TCP 짧은 연결

TCP 짧은 연결의 상황을 시뮬레이션해 보겠습니다. 클라이언트가 서버에 연결 요청을 시작하고, 서버가 요청을 수신한 후 두 당사자가 연결을 설정합니다. 클라이언트가 서버에 메시지를 보내고 서버가 클라이언트에 응답하면 읽기 및 쓰기가 완료됩니다. 이때 어느 쪽이든 닫기 작업을 시작할 수 있지만 일반적으로 클라이언트가 닫기 작업을 먼저 시작합니다. 이유는 무엇입니까? 일반적으로 서버는 클라이언트에 응답한 후 즉시 연결을 닫지 않습니다. 물론 특별한 상황을 배제할 수는 없습니다. 위의 설명에 따르면 짧은 연결은 일반적으로 클라이언트/서버 간에 하나의 읽기 및 쓰기 작업만 전송합니다

짧은 연결의 장점은 관리가 상대적으로 간단하고 기존 연결이 모두 유용한 연결이므로 추가 작업이 필요하지 않다는 것입니다. 제어 방법

　3.3 TCP 긴 연결

다음으로 클라이언트가 서버에 대한 연결을 시작하고, 서버가 클라이언트 연결을 수락하고, 두 당사자가 연결을 설정하는 상황을 시뮬레이션합니다. 연결. 클라이언트와 서버가 읽기 및 쓰기를 완료한 후에는 둘 사이의 연결이 적극적으로 닫히지 않으며 후속 읽기 및 쓰기 작업에서는 계속해서 이 연결을 사용합니다.

먼저 TCP/IP의 자세한 설명에서 언급한 TCP 연결 유지 기능에 대해 이야기하겠습니다. 연결 유지 기능은 주로 서버 응용 프로그램에 제공됩니다. 서버 응용 프로그램은 클라이언트 호스트가 충돌했는지 여부를 알고 싶어합니다. , 클라이언트를 대신하여 리소스를 사용할 수 있도록 합니다. 클라이언트가 사라지고 서버에 반개방형 연결이 남아 있고 서버가 클라이언트의 데이터를 기다리고 있는 경우 서버는 클라이언트의 데이터를 기다립니다. 연결 유지 기능은 이 반개방형 연결을 감지하려고 시도합니다. 서버 측에서 연결하십시오.

2시간 이내에 특정 연결에 대한 조치가 없으면 서버는 클라이언트에 프로브 세그먼트를 보냅니다. 클라이언트 호스트는 다음 네 가지 상태 중 하나에 있어야 합니다.

클라이언트 호스트는 여전히 정상적으로 실행 중이며 서버에서 연결할 수 있습니다. 클라이언트의 TCP 응답은 정상이며, 서버도 상대방이 정상임을 알고 2시간 후에 연결 유지 타이머를 재설정합니다.

클라이언트 호스트가 충돌하여 종료되거나 재부팅되는 중입니다. 두 경우 모두 클라이언트의 TCP로부터 응답이 없습니다. 서버는 프로브에 대한 응답을 받지 못하며 75초 후에 시간 초과됩니다. 서버는 각각 75초 간격으로 총 10개의 프로브를 보냅니다. 서버가 응답을 받지 못하면 클라이언트 호스트가 닫혔다고 가정하고 연결을 종료합니다.

클라이언트 호스트가 충돌하여 다시 시작되었습니다. 서버는 연결을 종료하게 만드는 재설정인 Keepalive 프로브에 대한 응답을 받게 됩니다.

클라이언트는 정상적으로 실행 중이지만 서버에 연결할 수 없는 상황입니다. 이 상황은 2와 유사합니다. TCP가 찾을 수 있는 것은 프로브 응답이 수신되지 않는다는 것입니다.

　3.4 긴 연결과 짧은 연결의 동작 과정

짧은 연결의 동작 단계는 다음과 같습니다.

연결 설정 - 데이터 전송 - 연결 닫기...연결 설정 - 데이터 전송 - 연결 끊기

긴 연결의 작업 단계는 다음과 같습니다.

연결 설정 - 데이터 전송... (연결 유지)... 데이터 전송 - 연결 끊기

　4. 긴 연결과 짧은 연결의 장단점

위에서 알 수 있듯이 긴 연결은 TCP 설정 및 종료 작업을 더 많이 절약하고 낭비를 줄이고 비용을 절감할 수 있습니다. 시간. 리소스를 자주 요청하는 고객에게는 긴 연결이 더 적합합니다. 하지만 여기에는 문제가 있습니다. 생존 기능의 탐지 기간이 너무 길고, 이는 TCP 연결의 생존만 탐지하며, 악의적인 연결이 발생할 경우 연결 유지 기능으로는 충분하지 않습니다. . 긴 연결의 응용 시나리오에서 클라이언트는 일반적으로 클라이언트와 서버 간의 연결을 적극적으로 닫지 않습니다. 클라이언트 연결 수가 증가하면 서버가 곧 문제가 됩니다. 또는 나중에는 더 이상 견딜 수 없는 때가 올 것입니다. 이때 서버는 오랫동안 읽기 또는 쓰기 이벤트가 없는 일부 연결을 닫는 등의 몇 가지 전략을 채택해야 합니다. 서버 측 서비스에 손상을 일으키는 악의적인 연결, 다시 허용되는 경우 클라이언트 시스템은 세분화되어 있으며 각 클라이언트에 대한 최대 긴 연결 수를 제한합니다. 이를 통해 문제가 있는 클라이언트가 백엔드 서비스에 영향을 미치는 것을 완전히 방지할 수 있습니다. .

짧은 연결은 서버 관리가 비교적 간단합니다. 기존의 모든 연결은 유용한 연결이며 추가 제어 방법이 필요하지 않습니다. 그러나 클라이언트가 자주 요청하면 TCP 설정 및 종료 작업에 시간과 대역폭이 낭비됩니다.

긴 연결과 짧은 연결의 출현은 클라이언트와 서버가 채택한 마감 전략에 달려 있습니다. 완벽한 선택은 없고 적합한 선택만 있습니다.

5. 긴 연결과 짧은 연결은 언제 사용하나요?

긴 연결은 주로 빈번한 작업, 지점간 통신에 사용되며 연결 수가 너무 많아지면 안 됩니다. 각 TCP 연결에는 3단계 핸드셰이크가 필요하며, 각 작업을 먼저 연결한 후 실행하면 처리 속도가 많이 떨어지므로 각 작업 후에 연결이 끊어지지 않고 데이터 패킷이 직접 전송됩니다. 첫 번째 처리는 괜찮습니다. TCP 연결을 설정할 필요가 없습니다. 예를 들어 데이터베이스 연결에는 긴 연결이 사용됩니다. 짧은 연결로 자주 통신하면 소켓 오류가 발생하고 소켓을 자주 생성하는 것도 리소스 낭비입니다.

WEB 웹 사이트와 같은 HTTP 서비스는 일반적으로 짧은 링크를 사용합니다. 긴 연결은 서버의 특정 리소스를 소비하기 때문입니다. WEB 웹 사이트와 마찬가지로 짧은 연결을 사용하는 경우에는 수천 또는 심지어 수억 개의 클라이언트 연결이 자주 발생합니다. 긴 연결을 사용하고 동시에 수천 명의 사용자가 있는 경우 각 사용자가 하나의 연결을 점유하는 것이 가능합니다. 따라서 동시성 양은 크지만, 빈번한 작업이 필요하지 않은 경우 각 사용자는 짧은 연결을 사용해야 합니다.