산소같은 HTTP 개념 공부

Castle_Junny·2023년 3월 9일

프로젝트를 진행하면서 한번에 최대 40개 가량 API를 호출하여 테이블과 차트를 그리는 상황이 있었다.
어떻게든 index를 먹여서 개발을 완료하고 운영 서버에 배포를 했는데 이게 왠걸?
로컬과는 다르게 테이블과 차트의 순서가 엉망이 되어 있었다.

이 문제는 어떻게든 해결했지만 그 원인에 대해서 자세히 알기 위해서 http에 대해서 공부해보았다.

0. HTTP?

Hypertext Transfer Protocol(HTTP) 인터넷에서 데이터를 주고받기 위한 통신 규약(약속) 중 하나로 브라우저와 웹 서버간에 데이터를 주고 받을 때 사용된다. 요청(request) , 응답(response) 구조로 이루어 짐

HTTP 요청을 서버로 보낼 때 GET, POST, PUT, DELETE와 같은 HTTP 메소드와 리소스의 URL 등을 포함하여 보낸다.

이렇게 HTTP를 통해 서버로 요청, 응답을 주고 받는데, 주고 받는 과정이 시간이 지나면서 어떻게 진화가 되었는지 공부를 해보았다.

0.1 TCP 와 UDP

1. TCP(Transmission Control Protocol)

인터넷 상에서 데이터를 메세지 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
연결지향 프로토콜이다.
데이터 전송하기 전에 먼저 연결을 맺고, 연결이 유지되는 동안 데이터를 전송하고 연결을 끊는다.
데이터의 신뢰성을 보장하기위해 패킷의 손실을 검사하고 재전송하며, 패킷의 순서를 보장한다.
TCP는 신뢰성 있는 데이터 전송을 보장한다.
스트림 전송으로 전송 데이터의 크기가 무제한이다.
1:1 통신이다.

2.UDP(User Datagram Protocol)

비 연경설 프로토콜이다.
데이터 전송하기전에 연결을 맺지 않는다.
데이터의 신뢰성이나 순서를 보장하지 않는다.
빠른 전송속도와 낮은 지연 시간을 보장하며, 실시간 게임, 영상 전송, DNS 등 데이터 손실이나 완벽성이 중요하지 않는 곳에 사용
데이터그램(메세지) 다뉘로 전송되며, 65535byte 로 크기제한이 있다. 초과 시 잘림
1:1 / 1:n / n:n 통신

3. 차이

데이터 전송 전 연결의 유무와 데이터 전송 방식이다.
TCP는 연결 지향성과 신뢰성을 보장 ⇒ 안정적
UDP는 연결 지향성이 없고, 데이터 전송 방식이 간단 ⇒ 신속함
데이터 크기 제한이 있다.

1. HTTP/1.0

기본적으로 하나의 연결 당 하나의 요청을 처리할 수 있게 설계 되었고( 1요청 1연결), 이는 RTT 증가를 야기한다.
- RTT란 ?
  - Round Trip Time(RTT)의 약자로, 데이터 패킷을 보내고 응답을 받는 데 걸리는 시간을 의미
- 패킷이란?
  - 패킷은 컴퓨터 네트워크에서 정보를 전송하는 단위이다.
  - HTTP/1.x의 경우 요청과 응답을 주고 받을 때 매번 새로운 연결을 맺어야 하기 때문에 RTT가 증가합니다. 이에 반해 HTTP/2와 HTTP/3는 하나의 연결에서 여러 요청과 응답을 처리하므로 RTT를 줄일 수 있습니다.
RTT 증가는 서버로부터 파일을 가져올 때 마다 TCP의 3-way handshake를 계속 열어야 하기 때문에 RTT가 증가하는 단점이 있다.
- TCP의 3-way-handshake란?
  - TCP/IP 프로토콜을 이용하여 통신하기 이전에 정확한 전송을 보장하기 위해(신뢰성있는 커넥션을 만들기 위해) 상대방 컴퓨터와 세션을 수립하는지 확인하는 과정을 의미
  - SYN = synchronize sequence numbers
    TCP에서 세션을 성립할 때 가장 먼저 보내는 패킷
    시퀀스 번호를 임의로 설정하여 세션을 연결하는데 사욛
  - ACK= acknowledgment (승인)
    서버로 부터 패킷을 받았다는걸 알려주는 패킷
HTTP/1.0의 RTT 증가 해결을 위한 방법
- 이미지 스플리팅
  - 많은 이미지 다운로드 시 과부하가 걸리기 때문에 많은 이미지가 합쳐있는 하나의 이미지를 다운 받고 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법
  - ZUM에서 아이콘을 개발자모드로 보면 하나의 background-image를 position을 이동하여 사용하는 것을 볼 수 있다.
- 코드압축
  - 코드를 압축하여 개행문자, 빈칸을 없애서 코드 크기를 최소화
- 이미지 Base64 encoding
  - 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 것
  - 서버와의 열결을 열고 이미지에 대해 HTTP 요청 할 필요가 없어지는 장점이 있지만 37% 정도 크기가 커지는 단점이 있다. (링크)

2. HTTP1.1

HTTP/1.1 에서는 하나 이상의 요청에 대해 연결을 재사용할 수있도록 keep-alive라는 메커니즘을 도입했다.

keep-alive
- 클라이언트가 모든 요청에 대해 TCP 3-way-handshake를 할 필요가 없기에 요청 지연시간을 줄였다.
HTTP pipelining(파이프라이닝)
- 클라이언트는 서버로 응답을 받기 전에 여러 요청을 보낼 수 있다.
- 요청에 대한 응답은 요청과 동일한 순서로 수신되어야 한다.
- 하지만 올바르게 구현하기 까다롭고 프록시 서버에서 파이프 라인을 제대로 처리하지 못했다.
- 또한 HOL Blocking이라는 문제도 있다.
HOL Blocking(Head of Line Blocking)
- 네트워크에서 전송하는 데이터 패킷은 일반적으로 송신 버퍼에서 큐(Queue)에 들어가서 전송된다.
- 수신 측에서는 이 패킷을 순서대로 수신하기 위해 기다리게 되는데, 만약 받는 쪽에서 데이터 처리 속도가 전송속도보다 느리다면 패킷이 쌓이게 된다.
- 이 때 지연되는 패킷 때문에 발생하는 성능 저하 현상을 말한다.

3. HTTP/2

HTTP/2는 여러 요청 Stream을 보낼 수 있는 HTTP Stream을 도입. HTTP/1.1 파이프라이닝(Pipelining)과 달리 각 Stream은 독립적이며 순서대로 전송하거나 수신할 필요가 없다.

HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며, 멀티 플렉싱, 헤더 압축, 서버 푸시, 요청의 우선 순위를 처리를 지원하는 프로토콜이다.

멀티플렉싱
- 여러 개의 스트림을 사용하여 송수신 하는 것
- 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작된다
  - 스트림(Stream)
    - 데이터 패킷을 의미한다. 대부분의 인터넷을 통해 전송되는 데이터는 일련의 데이터 패킷으로 나뉘어 전송된다. 이 패킷들은 서버(server)에서 클라이언트(client)까지 여러 노드(node)를 거쳐 전달되어 파일을 완전히 복원되기에이 패킷들의 순서는 Stream의 특성상 중요하다.
    - 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름
header 압축
- HTTP/1.x에서는 큰 header의 크기기가 문제였다. 이를 HTTP/2에서는 허프만 코딩 압축 알고리즘을 사용하여 압축하였다.(HPACK)
서버푸시(Server Push)
- 기존에는 클라이언트가 웹 서버에 요청을 해야 파일을 다운로드 받을 수 있었다면, HTTP/2에서는 클라이언트 요청 없이 웹 서버가 바로 리소스를 푸시할 수 있다.
- 이러한 기능한 클라이언트가 요청한 리소스를 받아오는데 필요한 요청-응답 프로세스를 생략하므로 로딩 속도를 향상시킬 수 있다.

4. HTTP/3

HTTP/2(TCP 기반)와는 달리 QUIC(Quick UDP Internet Connections)은 UDP 기반으로 동작한다.

QUIC는 HOL Blocking을 방지하고 데이터 전송 속도를 향상시킬 수 있다.

하나의 연결에서 여러 요청을 할 수 있고, 각각의 요청은 개별 Stream으로 전송된다. 이때 하나의 Stream에서 발생하는 패킷 손실이 다른 Stream에 영향을 미치지 않는다. (TCP의 세션 연결 및 끊는 과정에서 발생하는 지연시간을 줄임)

이러한 특성을 가진 HTTP/3은 웹 페이지 로딩 속도를 개선할 수 있다.

느낀 점

이번 공부를 통해서 서론에서 말한 순서가 왜 엉망이었는지 원인을 파악할 수 있었다.
바로 개발서버와 운영서버에서 사용하는 http 프로토콜의 버전(?)이 달랐다.
개발 서버는 http1.x 이고 운영서버은 http3.0으로 구성되어 있었다.

안그래도 개발하면서 "왜 개발서버에서는 API가 한번에 최대 4개? 6개? 밖에 안날라가지?" , "왜 계속 pending 되지?" 라는 생각을 했었는데, 이번 http공부르 하면서 왜 4~6개 밖에 호출이 안됐는지 원인을 찾을 수 있었다. (뿌듯...)
=> http/1.x의 한계..

실무를 하면서 매번 느끼는게 "코딩만 잘해서 될게 아니다." 라는 생각을 많이 하게 된다.

코딩을 아무리 잘해도 코딩 외의 문제에 부딪히게 되면 아무것도 아니게 되겠다는 생각을 자주 한다.
틈틈히 CS공부도 해서 관련 지식을 많이 채워 넣어야겠다.

아무튼, 더 늦기전에 http에 대해서 많이 이해할 수 있는 시간이었고 나중에 비슷한 환경에 놓이게 되면 유연하게 대처할 수있게 준비할 수 있을 거 같다.

주말에 인프런의 김영한님의 http강의를 보며 다시 한번 http 공부를 해야겠다.

.
.
.
.