OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP(from1) 또는 UDP 시스템 위에서 HTTP(from2)와 같은 것들이 작동함을 시사한다. 다시말해 HTTP 응답 데이터를 읽어 받아 웹 페이지에 예쁘게 띄우는 역할을 수행하는 클라이언트 애플리케이션인 웹 브라우저(from3:웹 서버와 웹 브라우저)는 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 관여하지 않아도 된다는 이야기이다(참고1,참고5:HTTP는 UDP를 사용할 수 있다).

실제로 HTTP1.1 문서를 인용하면 다음과 같다.

This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.(참고3)

그림(참고4)

하지만 HTTP는 UDP를 위해 설계되지 않았을뿐더러, UDP를 이용하는 경우 문제가 생기기 때문에 사용하지 못하도록 브라우저 등에서 기능을 지원하지 않을 뿐이다(참고2:발생할 수 있는 문제들).

애플리케이션이 자신이 받은 데이터에 대한 프로토콜을 신경쓰지 않는 이유를 구현의 측면에서 생각해보면, 저수준에서 소켓을 생성할 때부터 TCP 혹은 UDP 통신 방식을 결정하기 때문이라고 생각할 수도 있다(sup1). 해당 소켓으로부터 값을 읽고 쓰는 애플리케이션 입장에서는 TCP 혹은 UDP 를 결정할 수 있는 권한이 없다.

TCP, UDP, HTTP?

websocket vs socket vs HTTP?

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.

1. None

from : 과거의 어떤 생각이 이 생각을 만들었는가?

1. ‣
2. [bc1.1. title: 서버와 클라이언트의 약속 HTTP 는 지속되지 않고(Connectionless), 새로운 연결마다 모든 상태를 잃어버리기 때문에 스테이트리스(Stateless)시스템이다.](https://janghoo.notion.site/bc1-1-title-HTTP-85eb5906948648d787f33d4becce2e0f)
3. ‣

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?