HTTP는 어떻게 stateless가됩니까?

HTTP는 상태 비 저장이라고합니다. 즉, 데이터 전송을 위해 정보를 저장할 필요가 없습니다.

그러나 HTTP는 상태 지향 TCP를 사용합니다.

그렇다면 HTTP는 어떻게 stateless가됩니까?

HTTP는 자체가 무국적 임에도 불구하고 자신을 전송하는 데 사용되는 하위 수준 프로토콜에 관심이없고 독립적입니다.

전송 기술은 TCP, Novell의 이전 SPX 또는 SCTP 또는 기타 꿈이 될 수 있으며 HTTP는 여전히 동일하게 작동합니다. HTTP에는 스트리밍 또는 연결 지향 프로토콜이 필요하며 해석 가능한 URL에 따라 달라 지지만 어떻게 달성되는지는 중요하지 않습니다.

이것이 계층 모델 또는 네트워크 스택이 존재 하는 이유 중 하나입니다 . 응용 프로그램 계층이 하위 계층과 관련이있을 필요는 없습니다.

하위 수준 프로토콜이 상태 저장이라고해서 그 위에 아무것도 자동으로 상태 저장이되거나 상태 저장이 필요한 것은 아닙니다.

HTTP 자체는 상태 비 저장입니다. 따라서 애플리케이션은 상태를 설정하기 위해 HTTP 위에 다른 계층을 구현해야합니다. 이것은 일반적으로 세션 쿠키로 수행됩니다.

"HTTP는 상태 비 저장"은 각 HTTP 트랜잭션 (요청-응답 쌍)이 이전 요청-응답 쌍의 상태와 독립적으로 처리 될 수 있음을 의미합니다.

특정 요청-응답 쌍을 전송하려면 임의의 큰 블록과 임의의 큰 블록을 임의의 블록으로 전달할 수 있고 제한된 패킷 크기의 레이어를 통해 TCP를 상태 저장해야하는 프로토콜이 필요합니다.

그러나 트랜잭션 경계를 넘어서는 상태가 없습니다. 클라이언트는 연결을 끊고 다음 요청을 위해 새 연결을 설정할 수 있습니다. 사실 그것은 초기 버전에서 유일한 옵션이었고 클라이언트가 Connection: keep-alive헤더를 포함하지 않으면 여전히 작동합니다 .

다음 요청은 다른 서버에서 쉽게 처리 할 수 ​​있으며 서버가 상태를 유지할 필요가 없기 때문에 클라이언트는 알 수 없습니다 (응용 프로그램이 일반적으로 세션 형태로 HTTP 위에 자체 상태를 추가하지 않는 한 결과로 발생하는 합병증) 로드 밸런싱에서 HTTP에 상태 저장 프로토콜을 구축하는 것에 대한 처벌이 있습니다. 이는 사용량이 많은 서버의로드 균형 조정에서 활용됩니다.

HTTP의 "상태 비 저장"특성은 이 계층에서 상태 정보가 생성되거나 사용되지 않음을 의미합니다 .

HTTP 인증과 같은 몇 가지 인스턴스에서이를 볼 수 있으며 자격 증명은 모든 요청과 함께 전송되며 영구 연결은 실제로 최적화입니다 (즉, 자격 증명을 보내면 서버는 요청 후에도 잊어 버립니다) 연결이 열립니다).

반대로 쿠키 기반 로그인 메커니즘은 상태 저장이지만 HTTP의 일부는 아닙니다.

당신은 그것을 하나의 내부에 가지고있는 러시아 인형 세트 (또는 원하는 경우 상자)로 이해해야합니다. TCP는 HTTP를 "내부"로 운반하지만 TCP는 그것의 특징이나 기능에 신경 쓰지 않습니다.

전체 그림을 얻으려면 OSI 모델 에 대해 더 명확하게 읽을 것을 권장 합니다.

TCP는 OSI 모델에서 HTTP 아래에 몇 개의 계층에 위치하며 각 계층은 실제로 다른 프로토콜에 해당합니다.

우리의 경우 HTTP는 프리젠 테이션 및 애플리케이션 계층에 있고 TCP는 전송 계층에 있습니다. 또는 TCP / IP 모델을 사용하는 경우 TCP 및 IP 프로토콜 모두 응용 프로그램 및 프리젠 테이션 계층의 네트워크 링크 계층과 HTTP에 있습니다.