Search
🔵

bc9.3_1. title: OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP 또는 UDP 시스템 위에서 HTTP가 작동함을 시사한다. 예를 들어 브라우저는 자신이 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 신경쓰지 않아도 된다.

생성
prev summary
🚀 prev note
next summary
🚀 next note
♻️ next note
bc9.3_2. title: WebRTC와 같은 프로토콜은 HTTP와 같이 OSI 7계층 구조의 특정 레이어에 속하는 개념으로 볼 수 없다. WebRTC는 OSI 7계층 구조의 여러 레이어를 통틀어 말하는 개념이다.
bb7.1.1.4. title: HTTP가 주로 사용하는 TCP의 오버헤드를 최소화하기 위해 연결이 지속가능하게 하거나(HTTP2.0) UDP를 기반으로 새로운 프로토콜을 정의하여 HTTP의 기본 전제인 신뢰성(reliablity)을 확보하려는 시도도 있다(HTTP3.0).
💡 아이디어조각
11 more properties
OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP(from1) 또는 UDP 시스템 위에서 HTTP(from2)와 같은 것들이 작동함을 시사한다. 다시말해 HTTP 응답 데이터를 읽어 받아 웹 페이지에 예쁘게 띄우는 역할을 수행하는 클라이언트 애플리케이션인 웹 브라우저(from3:웹 서버와 웹 브라우저)는 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 관여하지 않아도 된다는 이야기이다(참고1,참고5:HTTP는 UDP를 사용할 수 있다).
실제로 HTTP1.1 문서를 인용하면 다음과 같다.
그림(참고4)
하지만 HTTP는 UDP를 위해 설계되지 않았을뿐더러, UDP를 이용하는 경우 문제가 생기기 때문에 사용하지 못하도록 브라우저 등에서 기능을 지원하지 않을 뿐이다(참고2:발생할 수 있는 문제들).
애플리케이션이 자신이 받은 데이터에 대한 프로토콜을 신경쓰지 않는 이유를 구현의 측면에서 생각해보면, 저수준에서 소켓을 생성할 때부터 TCP 혹은 UDP 통신 방식을 결정하기 때문이라고 생각할 수도 있다(sup1). 해당 소켓으로부터 값을 읽고 쓰는 애플리케이션 입장에서는 TCP 혹은 UDP 를 결정할 수 있는 권한이 없다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.
1.
None
from : 과거의 어떤 생각이 이 생각을 만들었는가?
1.
3.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?
참고 : 레퍼런스
2.
The final option to consider is to just let users send and receive UDP packets directly from the browser. Of course, this is an absolutely terrible idea and there are good reasons why it should never be allowed. (1) Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers. (2) New security holes would be created as JavaScript running in web pages could craft malicious UDP packets to probe the internals of corporate networks and report back over HTTPS. (3) UDP packets are not encrypted, so any data sent over these packets could be sniffed and read by an attacker, or even modified in transmit. (4) It would be a massive step back for web security to create a new way for browsers to send unencrypted packets. (5) There is no authentication, so a dedicated server reading packets sent from a browser would have to implement its own method to ensure that only valid clients are allowed to connect to it, which is well outside the amount of effort most game developers would be willing to apply to this problem.
5.
HTTP/3이 UDP 기반인 QUIC 프로토콜을 사용하는 이유가 바로 이런 제약 조건을 뛰어넘기 위해 프로토콜 자체를 손보는 방법을 택한 것이다. 하지만 TCP는 워낙 오래된 프로토콜이기도 하고 커널까지 내려가는 로우 레벨에서 정의되어 있기 때문에 이걸 뜯어고치는 것도 만만치 않은 대작업이라 UDP를 선택한 것이다. … TCP는 굉장히 친절한 프로토콜이다. 통신을 시작할 때와 종료할 때 서로 준비가 되어있는지를 반드시 먼저 물어보고 패킷을 전송할 순서를 정하고 나서야 본격적인 통신을 시작하기 때문이다. 이때 통신을 시작할 때 거치는 과정을 3 Way Handshake, 통신을 마칠 때 거치는 과정을 4 Way Handshake라고 한다. … TCP를 사용하는 이상 본격적인 통신을 시작하기 전에 무조건 저 번거로운 통신 과정을 거쳐야한다는 것이다. … HTTP/1은 하나의 TCP 연결에 하나의 요청만 처리하고 연결을 끊어버렸기 때문에 매 요청마다 이 번거로운 핸드쉐이크를 거쳐야 했다. 그래서 HTTP/2에서는 핸드쉐이크를 최소화하기 위해서 단일 TCP 연결을 유지하면서 여러 개의 요청을 처리할 수 있도록 변경된 것이다. 결국 HTTP/1에서 HTTP/2로 넘어갈 때도 핸드쉐이크 과정 자체는 건드리지 않았고 단지 핸드쉐이크가 발생하는 횟수를 최소화함으로써 레이턴시를 줄인 것이다. 이는 TCP를 사용하는 이상 핸드쉐이크가 반드시 필요한 과정이기 때문에 건드리지 못한 것이다.