[컴퓨터 네트워크 스터디 1주차] 컴퓨터 네트워크 와 HTTP 프로토콜

 

컴퓨터 네트워크와 네트워크 레이어

 

 컴퓨터 네트워크란 무엇인가?

     

컴퓨터 네트워크란 Net + Work 의 합성어로써 컴퓨터들이 통신 기술을 이용하여 그물망처럼 연결된 통신 이용 형태를 의미합니다.  간단하게 해석하자면 "두 대 이상의 컴퓨터들을 연결하고 서로 통신할 수 있는 것" 을 말합니다.하지만 최근에는 컴퓨터 뿐만 아니라 스마트폰 , 노트북 등 인터넷에 연결되는 다양한 기기들이 서로 연결되어 정보를 주고받는 것 또한 포함 되고 있습니다. 

네트워크란 연결하는 선이나 장치 같은 물리적인 측면부터 데이터를 주고받는 데에 필요한 메시지나 규약과 같은 물리적이지 않은 측면까지 모두 포함한 통신 과정 전체를 아우르는 개념입니다.

 

 현대 컴퓨터 네트워크에서 데이터를 어떻게 전달하는가?

 

오래 전에는 컴퓨터 간 데이터 통신을 '회선 교환' 이라는 방식을 사용했다. 회선 교환 방식은 통신하고자 하는 두 호스트가 데이터를 전송하기 전에 미리 데이터 이동 경로를 하나 설정해두는 방식이다. 즉 미리 설정해준 경로는 두 호스트만을 위한 전용 경로가 되고, 이 경로를 통해 통신의 처음부터 끝까지 모든 데이터가 왔다갔다 하는 것이다. 아래의 사진을 보면 호스트 A와 D가 통신을 하기 위해 1 -> 4 -> 7 을 따라서 모든 데이터가 이동하게 된다.

이 방식은 회선의 트래픽이나 이동 효율을 전혀 고려하지 않은 채 미리 정하는 방식이다. 보통의 통신이라 함은 데이터를 전송하는 시점의 트래픽, 혼잡도 등의 요인에 따라 효율이 달라지게 되는데, 회선 교환 방식은 데이터 전송 전에 이러한 요인을 고려하지 않고 이동 경로를 정해버리기 때문에 효율적이지 못하며 이미 설정된 이동 경로는 할당 해제 될 때까지 다른 호스트들이 사용할 수 없어 데이터를 전송하고 있지 않아도 연결 설정이 끊어지지 않는 이상 다른 호스트들은 해당 경로로 데이터 통신을 할 수 없게 된다.

 

또한 단절에 매우 취약하다. 두 호스트간의 연결이 끊어지면 이동 경로를 다시 연결해줘야 하고, 그 사이 다른 호스트가차지해버리면 해당 경로가 릴리즈 될 때까지 기다려야한다. 

 

이러한 단점들을 개선하기 위해 현대에는 새로운 통신 방식인 "패킷 통신" 이 생겨났다.

 

현대 데이터 통신 방식 "패킷 통신" 의 등장

 

"패킷 교환" 방식은 미리 이동 경로를 정하지 않고, 데이터를 패킷이라는 작은 단위로 나누어 다중 노드로 구성된 네트워크를 통해 전송하는 개념이다. 전송될 데이터는 네트워크를 통해 전송되기 전에 패킷으로 쪼개어지고, 각 패킷에는 고유 번호가 지정되어 있어서 네트워크를 거쳐 최종 수신지에 도착했을 때에 번호 순서대로 결합되 원래 데이터로 완성되는 방식이다.

 

각 패킷은 전송 당시 가장 효율적인 경로를 설정하여 최종 목적지까지 이동하게 된다. 회선 교환 방식과 다르게 상황에따라매번 다른 경로로 갈 수 있도록 하여 효율성을 증가시키는 방식이다. 그런데 애초에 이게 가능하려면 출발지부터 목적지까지 가는 과정에서 거치는 모든 중간 노드들이 그때 그때 상황에 따라 이동 경로를 안내해줄 수 있어야 하는 문제가 있다.

 

※ 라우터란? 

 

즉 위와 같은 문제를 패킷을 수신한 중간 노드가 패킷의 최종 목적지(수신지)를 확인하고, 목적지까지 가는 다양한 경로중 딱 그 상황에서 가장 최적이라고 판단되는 경로를 따라 패킷을 이동시키는 '라우팅' 을 해줘야 한다. 이러한 라우팅을 수행해주는 중간 노드를 '라우터'라고 한다.

 

데이터를 송신하는 호스트에서는 해당 네트워크가 사용하는 프로토콜을 기반으로 데이터를 작은 단위로 분할하고, 분할된 데이터를 각각의 앞에 패킷 번호, 송신지 및 수신지 정보 등 다양한 정보를 담은 패킷 헤더를 붙여 최종적으로 '패킷'이라는 형태로 변환하여 데이터를 전송하게 된다. 데이터들이 잘게 쪼개어져 패킷이라는 단위로 변환되는 과정을 '캡슐화'라고 한다.

 

 

패킷 각각의 라우팅은 중간 노드들의 혼잡도, 역량에 따르기 때문에, 패킷이 순서대로 수신 호스트에 도착한다는 보장은 없다. 따라서 수신호스트에서는 송신 호스트가 전송한 패킷이 모두 도착했음을 인지했을 때, 해당 네트워크의 프로토콜에 의거하여 패킷 헤더를 쭉 읽고, 패킷들의 순서를 정리해서 원래 데이터 형태로 정립하게 된다.

 

이러한 패킷 전송 방식을 사용하게 되면, 중간 노드 각각에서 다른 노드로 이동할 때마다 최적의 경로를 통해 이동하기 때문에 전송 효율이 매우 높고, 노드들 간의 경로를 어느 한 패킷이 독점하는 것이 아닌 공유하는 형태이기 때문에 회선 교환 방식보다 훨씬 효율적인 방식이다.

 

현대에는 거의 모든 통신이 패킷 전송 방식을 사용하고 있다. 따라서 현대의 정보통신 네트워크에서 데이터는 패킷으로 분할되어 라우터를 거쳐 전송되는 것이 기본 원리로 작용된다.

 

네트워크에서 데이터 전송 과정 실생활에 빗대어 보기

 

택배 보낼때 운송장 붙이는 행위도 캡슐화의 일종이라고 볼 수 있다. 해당 택배의 최종 목적지 정보(주소) 가 담겨있기 때문이다. 그리고 중간중간 거치는 택배 물류 Hub 의 경우에는 네트워크를 이루는 라우터라고 할 수 있겠다, 왜냐하면 각 Hub 에서는 가장 빠른 경로로 택배를 운송하기 위해 적절한 트럭에 상차시키는 행위를 하기 때문이다. 이는 라우팅에 빗댈 수 있다.

 

   

 라우터와 스위치

 

라우터는 서로 다른 네트워크를 상호 연결하여 더 넓은 네트워크를 형성하는 데 사용되는 장치이며 한 네트워크에서 다른 네트워크로의 최적의 경로를 찾아 패킷을 이동시키는 라우팅 기능을 제공하는 장치이다. 네트워크 계층에 해당하며 IP 주소를 기반으로 통신 한다.

 

스위치는 같은 네트워크 안에서 통신 장비들을 서로 연결해주어 자원을 쉽게 공유할 수 있도록 해주는 장치이다. 데이터 링크 계층에 해당하며 MAC 주소를 기반으로 통신 한다.

 

 프로토콜 스택 

 

프로토콜이란 네트워크 통신을 하기 위해서 통신 장비 사이에 정보를 주고 받는 규칙 또는 약속을 말한다. 

프로토콜을 정의하기 위해선 구문, 의미, 타이밍 이렇게 3가지 기본 요소가 필요하며 여러가지의 기능들이 있지만 이 부분은 다음 기회에 깊이있게 공부 후 정리 할 생각입니다.

 

프로토콜 스택을 설명하기에 앞서 시스템의 구조를  빗대어 설명하자면 시스템이 계층 구조를 가질 때, 그 계층이 제공하는 서비스의 구현을 변경하는 것은 매우 쉽고, 한 계층이 상위 계층에 같은 서비스를 제공하고 하위 계층의 서비스를 이용하는 한, 어떤 한 계층의 구현이 변하더라도 시스템의 나머지 부분은 변하지 않으므로 유지보수 측면에서 효율적이며 새로운 기능을 추가 , 수정 하기에도 편리하다. 이와 같이 다양한 계층의 프로토콜이 계층화된 구조로 모여 있는 프로토콜의 집합을 프로토콜 스택이라고 한다. 추가로 이 모양이 자료구조인 Stack과 비슷하다고 하여 이러한 이름을 가지게 되었다고 한다.

 

인터넷 프로토콜 스택은 크게 5개 계층(TCP/IP 5 Layer)과 7개 계층(OSI 7 Layer) 으로 구성되는데 , 7 계층인 OSI 모델은 국제 표준화 기구(ISO)가 데이터 통신의 규격과 프로토콜을 통일하기 위해 만들었습니다. 사실상 현대에는 잘 사용되어지고 있지 않으며 표준으로 받아들여지는 것은 TCP/IP 5 계층이 사용되어 지고 있다.

 

우측의 TCP/IP 모델이 현재 표준화되고 있는 모델이다.

 

 OSI 7 Layer &  TCP/IP 5 Layer

 

상단의 그림처럼 OSI 7 계층의 세션 , 표현 , 응용 계층이 TCP/IP 모델에서는 응용계층으로 통합되어 표현되므로 각각의 계층을 설명할 때는 OSI 7계층을 기준으로 정리 했다.

 

1계층 - 물리 계층(Physical Layer)

 

네트워크 데이터가 전송되는 물리적인 매체 이며 0 , 1 의 디지털 신호를 아날로그 신호로 변환하거나 혹은 그 반대로 변환하는 역할을 수행하며, 단순 데이터 만 전달하며 데이터 단위는 비트(Bit)이다.

대표적인 장비 : 통신 케이블 , 허브 , 랜카드 

 

2계층 - 데이터 링크 계층(DataLink Layer)

 

• 물리계층으로 송/수신되는 정보를 확인하고 오류 없는 통신을 위해 여러 역할을 수행한다 직접 연결된 서로 다른 2개의 네트워킹 장치 간의 데이터 전송을 담당한다.
• MAC 주소를 통해 통신한다.프레임에 Mac 주소를 부여하고 에러 검출 , 재전송 , 흐름 제어를 진행한다.
• 대표 장비 : 스위치 , 브릿지
• 데이터 단위 : 프레임(Frame)
• 하드웨어와 소프트웨어 특성을 둘 다 가진다(물리계층은 하드웨어적 특성을 가지고 , 네트워크 계층부터는 소프트웨어적인 특성을 가진다. 연결 다리 역할을 한다고 생각

MAC 주소란 

• 컴퓨터 간 데이터를 전송하기 위해 있는 컴퓨터의 물리적 주소 또는 하드웨어 주소
• 그 기계의 고유 번호 , 그 하드웨어만 가지고 있는 식별번호 (=주민번호)
• IP는 변할 수 있지만 MAC은 변하지 않는다.
• MAC 주소는 데이터링크 계층에 사용되고 , IP주소는 네트워크 계층에서 사용된다.

 

3계층 - 네트워크 계층(Network Layer)

 

• 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능(라우팅)을 담당한다(최적의 경로를 찾는다).
• 라우터를 통해 이동할 최적의 경로를 선택하여 IP 주소를 지정하고 , 해당 경로에 따라 패킷을 전달해준다.(= 패킷을 네트워크 간의 IP를 통하여 데이터를 전달한다)
• 라우팅 , 흐름제어 , 오류제어 , 세그먼테이션 등을 수행한다.
• 대표 장비 : 라우터
• 데이터 단위 : 패킷(Packet)

 

4계층 - 전송 계층(Transport Layer)

 

• 두 호스트 시스템으로부터 발생하는 데이터의 흐름을 제공한다.
• TCP와 UDP 프로토콜을 통해 애플리케이션 간의 통신을 담당한다. Port를 열어두고 , 프로그램들이 전송할 수 있도록 제공해준다.
• 데이터 단위 : 세그먼트(Segment)
• 프로토콜 종류 : TCP , UDP
  • TCP : 신뢰성 , 연결지향 , 데이터 송수신전 3-way-handshake , 연결을 끊기 전 4-way-handshake를 진행.
  • UCP : 비신뢰성 , 비연결성 , 실시간

 

5계층 - 세션 계층(Session Layer)

 

• 애플리케이션 간의 통신에서 세션을 관리한다. 운영체제가 통신을 하기 위한 세션을 확립 , 유지 , 중단하는 작업을 수행한다.
• 특정 지점에서 송수신 오류가 발생하면 이전에 동기점으로 설정한 통신이 완벽했던 지점부터 다시 재전송하는 동기화 기능이 있다.
• 프로토콜 종류 : SSH , TLS , RPC

 

6계층 - 표현 계층(Presentation Layer)

 

• 애플리케이션이 다루는 정보를 통신에 알맞은 형태로 만들거나, 하위 계층에서 온 데이터를 사용자가 이해할 수 있는 형태로 만드는 역할을 담당하는 계층
• 애플리케이션들이 교환되는 데이터의 의미를 해석하도록 하는 서비스를 제공
• 서비스 데이터 기술 뿐만 아니라 데이터 압축과 데이터 암호화도 가능

 

7계층 - 응용 계층(Application Layer)

 

• 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는 역할을 담당하는 계층
• 애플리케이션 목적에 맞는 통신 방법을 제공한다.
• 네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳
• 주로 데이터를 어떻게 보낼것인가 는 하위 레이어에서 구현하는 기능이다.
• 프로토콜 종류 : HTTP , SMTP , FTP ,DNS

 

 

HTTP 프로토콜

 

HTTP 프로토콜이란 무엇인가?

 

HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.애플리케이션 레벨의 프로토콜로 TCP/IP위에서 작동한다.

 

서버 / 클라이언트 모델이란 ?

서비스 제공자 와 서비스 요청자로 구분되는 네트워크 모델이다. 서비스 제공자의 역할을 하는 측을 서버 , 서비스 요청자의 역할을 클라이언트라고 한다. 서버 / 클라이언트 모델에서 모든 자원은 서버에 집중된다. 클라이언트는 데이터 프리젠테이션을 위한 최소한의 자원을 가지는게 일반적이다.

 

 Method

 

HTTP 메서드는 URL을 이용하여 클라이언트가 서버에게 특정 데이터를 요청할 수 있는데 이떄 요청하는 데이터에 특정 동작을 수행하고 싶을 때  서버에게 알려주기 위해서 사용된다.

• GET : 존재하는 자원에 대한 조회 요청
• POST : 새로운 자원을 생성
  • GET 과 POST 의 차이점
    • 사용 목적 : GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트 할 때 사용한다.
    • DB로 따지면 GET은 SELECT 에 가깝고 , POST는 INSERT 에 가깝다고 보면 이해하기 좋다.
    • 요청에 BODY 유무 : GET은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST는 body 에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다. 그러므로 POST가 보안에는 더 효과적이라고 할 수 있다.
• PUT : 존재하는 자원에 대한 변경
• PATCH : 존재하는 자원에 대한 변경
  • PUT 과 PATCH의 차이점
    • update 방식의 차이
      • PUT은 대상 리소스를 나타내는 데이터를 대체한다는 정의처럼 보내지 않은 값은 null로 대체된다.
      • PATCH는 주로 부분적인 수정을 할 때 사용한다는 정의처럼 보내지 않은 값은 기존의 값 그대로 유지되고 있다.
    • 요청한 URL에 자원이 존재하지 않을 때
      • PUT은 새로운 자원을 생성한다.
      • PATCH는 새로운 자원을 생성하지 않는다.
• DELETE : 존재하는 자원에 대한 삭제
• HEAD : 서버 헤더 정보를 획득 , GET과 비슷하나 Response Body를 반환하지 않음
• OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 주로 사용

이와 같이 데이터에 대한 조회 , 생성 , 변경 , 삭제 동작을 HTTP 요청 메서드로 정의할 수 있습니다. 참고로 떄에 따라서 POST메서드로 PUT,DELETE의 동작도 수행할 수 있습니다.

 

 HTTP Status Code

 

HTTP Status Code(HTTP 상태 코드) 는 클라이언트가 보낸 HTTP 요청에 대한 서버의 응답 코드로 , 상태 코드에 따라 요청의 성공/실패 여부를 판단합니다.

 

1xx(Informational) : 조건부 응답(거의 사용되지 않음)

 

2xx (Successful) : 성공

• 200 (ok) : 서버가 요청을 제대로 처리함
• 201 (created) : 요청이 성공했으며, 새로운 리소스가 생성됨
• 202 (Accepted) : 요청을 받았으나 아직 처리하진 않음
• 203 : 요청이 성공적으로 수행되었으나 , 요청에 대한 검증이 되지 않음
• 204(no Content) : 요청이 성공적으로 수행 되었고 , 응답 payload에 보낼 데이터가 없음을 의미합니다.
• 205 : 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다.
• 206 : 서버가 GET 요청의 일부만 성공적으로 처리했음을 의미.

3xx(Redirection) : 리다이렉션 완료

 

브라우저는 HTTP 헤더에 들어있는 Location 필드를 찾아 해당 필드가 존재할 경우, Location 필드에 담긴 URL로 자동으로 리다이렉트합니다.

출처 - https://velog.io/@sangyeon217/http-status-code

• 300 : 요청에 대해 하나 이상의 리소스가 존재함을 의미합니다.
• 301 : 요청한 리소스의 URI가 변경되었음을 의미합니다.
• 302 : 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다.
• 303 : 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때의 응답아더,
• 304 : 리소스가 수정되지 않음을 의미합니다.해당 응답을 받으면 클라이언트는 서버로부터 리소스를 재전송 받지 않고, 캐싱된 리소스를 사용합니다.

4xx(Clinet Error) : 요청 오류

클라이언트 오류(잘못된 문법 등)로 인해 서버가 요청을 처리할 수 없음을 의미합니다.

• 400(Bad Request) : 잘못된 문법으로 인해 클라이언트가 올바르지 못한 요청을 보내 서버가 요청을 이해할 수 없음을 의미한다.
• 401(Unauthorized) : 인증되지 않은 사용자가 인증이 필요한 리소스를 요청하는 경우의 응답이다. 보통 로그인이 필요한 API를 비로그인 사용자가 호출했을 때 사용된다.
• 403(Forbidden) : 클라이언트가 콘텐츠에 접근할 권한을 가지고 있지 않음을 의미한다.
• 404(Not Found) : 요청한 리소스가 존재하지 않음을 의미한다.
• 405 : 현재 리소스에 맞지 않는 메서드를 사용했음을 의미한다. 예로는 GET 요청만 허용되는데 POST요청을 한 경우의 응답이다.

5xx(Server Error) : 서버 오류

서버 오류로 인해 서버가 정상 요청을 처리하지 못함을 의미한다.

 

• 500 : 서버에 오류가 발생하여 응답할 수 없음을 의미한다. 
• 501 : 클라이언트 요청에 대한 서버의 응답 수행 기능이 없음을 의미한다.
• 502 : 서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미한다.

 

 Http Header

 

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다.

여기서 부가적 정보란 대표적으로 "요청자" , "컨텐트 타입", "캐싱" 등등이 있다. 

 

Header 의 종류

 

•  General header(일반 헤더) : 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.
  • Date : 메세지가 생성된 날짜와 시간 등을 가리킨다.
  • Cache-Control : 클라이언트와 서버에서 메세지 캐싱이 어떻게 이루어질지 지시한다.
  • Connection : 커넥션 관리에 대해 명시한다. 트랜잭션 이후에 커넥션을 계속 살릴지 끊을지를 결정한다.
• Request header(요청 헤더) : 클라이언트가 서버에 요청할 때 이용되는 헤더이다. 클라이언트가 사용하는 언어 정보 , 유저 에이전트와 받아들이는 미디어 타입에 대한 정보 등이 포함되어 있다.
  • user-Agent : 통신 시 어떤 브라우저 혹은 애플리케이션으로 접근했는지에 대해 명시한다.
  • Accept : 클라이언트가 이해할 수 있고 처리할 수 있는 Media type 에 대해 명시한다.
  • Accept-Language : 클라이언트가 선호하는 언어에 대해 명시한다.
  • Host : 요청이 보내지는 도메인 이름과 포트에 대해 명시한다.
• Response header(응답 헤더) : 서버의 응답에 대한 정보를 전달할 때 쓰이는 헤더이다. access control policies 혹은 쿠키와 같은 서버에 대한 정보를 포함한다.
  
  • Server : 요청을 처리하는 서버 소프트웨어에 대해 명시한다.
  • Content-Type : HTTP 바디에 들어있는 메시지의 Media type 에 대해 명시한다.
  • Content-Length : 응답 HTTP 바디의 길이를 명시한다.
  • Set-Cookie : 서버에서 클라이언트로 쿠키를 줄 때 사용한다.
  • Access-Control-Allow-Origin : cross-origin 요청에서 어떠한 origin 이 접근허용되었는지 명시한다.
• Entity  header(엔티티 헤더) : 보통 HTTP 바디에 대한 정보를 주기 위해 존재한다. 요청과 응답 헤더에서 모두 쓰인다.
  • Content-Type
  • Content-Encoding : 보통 압축 방식에 대한 정보를 주기 위해 사용된다
  • Content-Length

 

 HTTP Stateless(무상태성)

 

Stateless 이란 서버가 클라이언트의 상태를 보존하지 않는 특징이다. 

서버의 확장성에 용이하다는 장점이 있지만 , 쿨라이언트가 추가 데이터를 전송해야 하는 단점이 있다.

 

< -- > 상태유지(Stateful)란?

클라이언트의 요청1에 대한 상태를 해당 요청을 받은 서버A가 기억하고 있는 것으로 항상 같은 서버A가 유지되어야 할 것이다. 만약 서버 A에서 장애가 난다면 유지되던 상태 정보가 없어져 버리므로 처음부터 다시 요청을 해야 할 수 있다.

 

무상태 프로토콜이라면 클라이언트 요청1을 보낼 때, 데이터를 다 담아서 보내기 때문에 아무 서버나 호출할 수 있다.

무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능한 장점이 있다.

 

무상태(stateless)의 한계
로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만, 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다. 이러한 상태 유지는 최소한만 사용한다.

 

비연결성 모델 (Connectionless)

비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다. 최소한의 자원으로 서버를 유지한다.

 

HTTP Keep-Alive

 

HTTP 프로토콜에서 클라이언트와 서버 간 여러 요청을 단일 TCP 연결을 재사용하는 방식으로 처리하는 기능을 말합니다. HTTP/1.1 프로토콜부터 도입됐습니다. 이 기능을 활성화하면 여러 HTTP 요청 및 응답 과정에서 발생하는 네트워크 오버헤드를 줄일 수 있습니다.

 

keep-alive를 사용하는 경우 HTTP 요청 헤더에 Connection: Keep-Alive라는 값을 포함시킵니다.

 

 

HTTP Keep-Alive의 효과

keep-alive가 없으면 클라이언트와 서버는 각 요청과 응답에 대해 매번 새로운 TCP 연결을 생성하고 닫아야 합니다.

이 방식은 네트워크 리소스가 비효율적으로 사용됩니다. 반면 keep-alive를 사용하면 단일 TCP 연결에서 여러 요청과 응답이 이루어지기 때문에 네트워크 지연 시간이 줄어들고 웹 사이트 성능이 좋아집니다.

 

초기 HTTP/1.0 프로토콜에서는 각 HTTP 요청에 대해 매번 TCP 연결을 새로 생성해야 했기 때문에 위에서 언급한 문제들이 존재했습니다. 이를 해결하기 위해 HTTP/1.1 프로토콜에 해당 기능이 도입됐습니다.

 

Keep-Alive 사용 예시

1. keep-alive 비활성화

웹 브라우저가 웹 서버에 html 페이지를 요청합니다. 웹 서버는 html 페이지를 전송하고 연결을 종료합니다. 웹 브라우저가 이미지 파일을 요청하기 위해 새로운 연결을 맺습니다. 웹 서버는 이미지 파일을 전송하고 연결을 종료합니다.

 

2. keep-alive 활성화

웹 브라우저가 웹 서버에 html 페이지를 요청합니다. 웹 서버가 html 페이지를 전송하고 연결을 유지합니다. 웹 브라우저가 이미지 파일을 요청합니다. 이때 기존 연결을 재사용해서 요청을 전송합니다. 웹 서버는 이미지 파일을 전송하고 연결을 유지합니다. 이 과정이 반복됩니다.

 

 HTTP 파이프라이닝

 

Pipelining이란 여러개의 요청을 보낼 때 처음 요청이 응답될 때까지 기다리지 않고 바로 요청을 한꺼번에 보내는 것을 의미한다.

keep-alive를 전제로 하며, 서버간 요청의 응답속도를 개선시키기 위해 적용한다.

서버는 요청이 들어온 순서대로 응답을 반환한다.

 

하지만 응답 순서를 지키기 위해 응답 처리를 미루기 때문에 Head Of Line Blokcing 문제가 발생하여, 모던 브라우저들은 대부분 파이프라이닝을 사용하지 못하도록 막아 놓았다.

 

Head-Of-Line 블로킹 이란 네트워크에서 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다.

 

HTTP/1.1 , HTTP/2 , HTTP/3

 

HTTP / 1 

 

HTTP/1은 기본적으로 연결당 하나의 요청을 처리하도록 설계되어 있고 동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어집니다.

HTTP 통신은 TCP를 기반으로 요청하며 TCP는 3-way Handshake, SSL과 같은 암호화가 추가 된다면 TLS handshake로 인한 RTT(왕복시간 / Round Trip Time)이 증가합니다.

특정 전송을 받아오지 못한다면 재요청을 하여 다시 데이터를 받아와서 신뢰성을 높이지만 재요청 시간만큼 통신이 지연됨을 알 수 있습니다. 이를 HOL(Head Of Line) 블로킹 이라하며 TCP기반의 HTTP 통신의 문제점이라고 볼 수 있습니다.

 

HTTP / 2

 

구글에서 2009년에 SPDY 프로토콜을 발표하였고 HTTP/2 프로토콜로 SPDY가 채택되어 2015년에 공식적으로 HTTP/2로 발행되었습니다. HTTP/2는 헤더 프레임과 데이터 프레임으로 나눠서 처리하고 있습니다. 이를 바이너리 프레이밍 계층이라고 하며 바이너리 형식으로 인코딩 되어 처리 할 수 있습니다.

HTTP/2는 바이너리 프레이밍 계층을 통해서 스트림 단위로 병렬로 처리합니다.

이를 멀티플렉싱이라고 하며 이를 통해서 TCP의 문제인 HOL로 생기는 재전송 시간지연을 제거함을 알 수 있습니다.

 

HTTP/2에서는 하나의 요청으로 서버에 모든 데이터를 클라이언트에 푸시 할 수 있게 되었습니다.

 

HTTP / 3

 

HTTP / 3는 QUIC라는 프로토콜을 이용하며 QUIC는 UDP를 사용하여 인터넷 연결을 합니다.

기존 HTTP는 신뢰성을 위해 TCP와 속도를 위한 UDP 방식을 동시에 사용하였지만 HTTP/3는 QUIC기반으로 UDP만을 사용합니다.

 

'UDP를 사용한다면 HTTP/3는 신뢰성이 떨어지지 않는가?'라는 생각이 들 수 있습니다.

그래서 HTTP/3는 QUIC계층을 추가하여 TCP와 같은 신뢰성을 제공합니다.

HTTP2의 멀티플랙싱의 기술으로 하나의 연결로 다수의 병렬 스트림 데이터를 동시 전송하고 TCP와 같은 순서에 맞는 전송을 진행하고 전송이 실패된 패킷을 재전송을 하여 완료 신뢰성을 높였고 TLS 암호화를 기본적으로 적용하기 때문에 기본적으로 보안성도 높다는 것을 알 수 있습니다.

 

 

 

참고 - https://velog.io/@haero_kim/%EB%AC%BC-%ED%9D%90%EB%A5%B4%EB%93%AF-%EC%9D%BD%EC%96%B4%EB%B3%B4%EB%8A%94-TCPIP