HTTP 1.1
- 데이터는 문자열로 전송
- 연결당 하나의 요청과 응답을 처리. 동시전송 문제와 다수의 리소스를 처리하기에 속도와 성능의 문제를 갖고 있음
- HOL-Blocking 발생, RTT(Rount Tript Time)의 증가
- 매 요청시 마다 쿠키 정보를 헤더에 포함시키고 중복된 헤더 값을 전송
HTTP 2.0
- 데이터는 바이너리로 인코딩하여 압축해서 전송
- Multiplexed Streams 방식이 도입되어 한번의 연결로 여러개의 메세지를 동시에 주고 받을 수 있음. 그러므로 HOL-Blocking이 발생하지 않음
- Stream Prioritization: 요청 리소스간 우선순위를 설정하여 응답을 빨리 받을 수 있음
- Header Compression: 헤더 정보를 HPACK 압축 방식을 이용하여 압축 전송
- Server Push: 클라이언트 요청 없이 서버에서 리소스를 보내줄 수 있음
HTTP 3.0
- quic 프로토콜 사용
- UDP 사용
- 전송 순서 보장안됨
HTTP에서의 HOL Blocking
HTTP/1.1의 요청-응답 쌍은 항상 순서를 유지하고 동기적으로 수행되어야 함
구체적으로 1개의 TCP 커넥션 상에서 3개의 이미지 (a.png, b.png, c.png)를 받는 경우, HTTP 리퀘스트는 다음과 같이 됨
|---a.png---|
|---b.png---|
|---c.png---|
하나의 요청이 처리되고 응답을 받은 후에 다음 요청을 보냄
이전의 요청이 처리되지 않았다면 그 다음 요청은 보낼 수 없음
만약 a.png의 요청이 막혀버리게 되면 b,c가 아무리 빨리 처리될 수 있더라도 전체적으로 느려지게 됨
|------------a.png------------|
|-b.png-|
|---c.png---|
이것이 바로 HTTP/1.1의 HOL Blocking
HTTP/1.1의 pipelining이라는 사양은 (조건부로) 요청만 먼저 보내버리는 것으로, 이 문제를 회피하는 것처럼 보임
그러나 응답을 보낸 순서대로 무조건 받아야 하므로 a.png가 막혔을 경우에 생각보다 큰 효과를 보기 어려움
TCP 와 UDP의 차이
TCP는 연결 기반 프로토콜로 데이터의 신뢰성과 순서를 보장하지만 속도가 상대적으로 느림
UDP는 연결이 필요없고 데이터 전송 속도가 빠르지만 데이터의 신뢰성과 순서 보장은 없음
TCP는 파일 전송, 이메일 등에 적합하며 UDP는 실시간 스트리밍, VolP에서 사용됨
728x90
반응형
'네트워크' 카테고리의 다른 글
TCP/IP의 상태 모델 별 개발자 작업 (0) | 2025.01.23 |
---|---|
RESTful API (0) | 2025.01.23 |
HTTP 헤더 (0) | 2025.01.22 |
TCP 3-way handshake, 4-way handshake (0) | 2025.01.22 |
HTTP & HTTPS (0) | 2025.01.21 |