HTTP - 4. 커넥션관리

SeulKing·2022년 4월 19일
HTTP완벽가이드http

네트워크

목록 보기
2/2
post-thumbnail
  • HTTP는 어떻게 TCP커넥션을 사용하는가
  • TCP 커넥션의 지연, 병목, 막힘
  • 병렬 커넥션, keep-alive 커넥션, 커넥션 파이프라인을 활용한 HTTP의 최적화
  • 커넥션 관리를 위해 따라야 할 규칙들

TCP 커넥션

💡 TCP ?
전송 제어 프로토콜(Transmission Control Protocol, TCP, 문화어: 전송조종규약)은 인터넷 프로토콜 스위트(IP)의 핵심 프로토콜 중 하나로, IP와 함께 TCP/IP라는 명칭으로도 널리 불린다.

💡 OSI ?
OSI 모형(Open Systems Interconnection Reference Model)은 국제표준화기구(ISO)에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다. 일반적으로 OSI 7 계층이라 불리기도 한다.

💡 TCP 커넥션 ?
TCP 커넥션은 클라이언트와 서버간에 주고받는 메시지들의 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달할 수 있도록 한다.
TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달된다.

URL을 입력받은 브라우저가 수행하는 7단계 과정 (TCP 커넥션을 사용하는 상황 예시)

예를 들어 velog.io/@sgsg9447 라는 URL에 접속한다고 가정해보자.
이때 브라우저(클라이언트)와 서버에서 발생하는 일은 아래와 같다.

  1. 브라우저가 velog.io/@sgsg9447라는 호스트 명을 추출한다.
  2. 브라우저가 호스트 명에 대한 IP주소를 찾는다.
  3. 브라우저가 포트 번호(80)를 얻는다.
  4. 브라우저가 아까 찾은 IP의 80 포트로 TCP 커넥션을 생성한다.
  5. 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다
  6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.
  7. 브라우저가 TCP 커넥션을 끊는다.

신뢰할 수 있는 데이터

TCP 목적: 신뢰성 있는 스트림 전송서비스의 제공

데이터의 중복이나 손실 없이 종단간 데이터의 전송을 보장함을 의미

❕어떻게?

  • TCP 커넥션은 인터넷을 안정적으로 연결해준다.
  • TCP 커넥션 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달된다.

TCP스트림은 세그먼트로 나뉘어 IP패킷을 통해 전송된다.


  • HTTP가 메시지를 전송할 때 현재 연결되어있는 커넥션을 통해서 메시지를 순서대로 보낸다.
  • TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다.
  • 이 모든 것은 TCP/IP 소프트웨어에 의해 처리된다.

IP 패킷이 포함하는 것

1. IP 패킷 헤더 (보통 20byte)
	발신자와 목적지 IP 주소, 크기, 기타 플래그
2. TCP 세그먼트 헤더 (보통 20byte)
	TCP 포트 번호, TCP 제어 플래그, 데이터의 순서와 무결성을 검사하기 위해 사용되는 숫자 값
3. TCP 데이터 조각 (0 혹은 그 이상의 byte)

TCP커넥션 유지

TCP 커넥션은 네 가지 값으로 식별한다.

<발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>

이 네 가지 값으로 유일한 커넥션을 생성한다.

TCP 소켓 프로그래밍

소켓(Socket)이란?
프로그램이 네트워크에서 데이터를 송수신할 수 있도록 "네트워크 환경에 연결할 수 있게 만들어진 연결부"
두 프로그램이 네트워크를 통해 서로 통신을 수행할 수 있도록 양쪽에 생성되는 링크의 단자이다.
두 소켓이 연결되면 서로 다른 프로세스끼리 데이터를 전달할 수 있다.
상대방에게 데이터를 보내거나 받는 역할을 한다.
우리는 이런 TCP 커넥션으로 원격 서버의 데이터를 읽고 쓸 수 있다. 클라이언트가 서버에게 커넥션을 요청하고, TCP 커넥션이 생성되면 HTTP 요청-응답을 주고받을 수 있다.
이떄 HTTP 요청-응답은 위의 그림처럼 아래에 TCP 계층이 있기 때문에 TCP 성능에 영향을 받는다.
TCP/IP 소켓 통신이란?

클라이언트 프로그램과 서버 프로그램은 각각 자신의 포트를 통해 통신을 해야 하는데, 소켓을 통해 연결한다.

TCP 성능에 대한 고려

HTTP는 TCP 바로 위에 있는 계층이기 때문에, HTTP 트랜잭션의 성능은 TCP 성능에 영향을 받는다.

HTTP 트랜잭션 지연


클라이언트는 URI 에서 웹 서버의 IP 주소와 포트를 알아내야 하는데,
해당 호스트에 방문한 적이 없다면 DNS resolution 을 통해 호스트 명을 IP 주소로 변환하는데 시간이 필요하다.
클라이언트가 서버에게 TCP 커넥션 요청을 보내고 서버가 커넥션 허용 응답을 회신하기를 기다린다.
커넥션이 맺어지면 클라이언트는 HTTP 요청을 새로 생성된 TCP 파이프를 통해 전송한다.
요청 메시지가 서버로 전달되고 서버에서 처리되는 데 시간이 소요된다.
웹 서버가 HTTP 응답을 보내는 데 시간이 소요된다.

TCP 네트워크 지연은 하드웨어 성능, 네트워크와 서버의 전송 속도, 요청과 응답 메시지의 크기, 클라이언트와 서버 간의 거리에 따라 크게 달라진다.

TCP커넥션 핸드셰이크 지연

작은 크기의 데이터 전송에 커넥션이 사용되면 HTTP 성능을 저하시킬 수 있다.

핸드 셰이크 과정을 간단히 묘사하자면
1. 클라이언트 -> 서버 [SYN]
2. 서버 -> 클라이언트 [SYN+ACK]
3. 클라이언트 -> 서버 [확인 응답]
4. 서버 -> 클라이언드 [데이터 전송]
1-2과정이 커넥션, 3은 잘 연결되었다는 확인 응답이다.

크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP 구성에 쓴다.

확인응답지연

TCP 세그먼트안에 들어가는 데이터에 TCP 순서 번호와 체크섬이 있다.
이때 각 세그먼트의 수신자는 세그먼트를 받았을 때 확인 응답 패킷을 송신자에게 반환한다.
송신자는 확인 응답 패킷을 대기하다가 특정 시간안에 받지 못한 경우는 전송에 문제가 있는 것으로 판단하고 데이터를 다시 전송한다.

확인 응답은 크기가 작기 때문에 송출되는 데이터 패킷에 확인 응답을 piggyBack한다.
이와 같은 piggyback을 늘리기 위해서, TCP 스택은 확인응답지연 알고리즘을 구현한다.
확인응답지연 알고리즘은, 특정 시간동안 버퍼에 데이터를 저장해놓고, piggyback 하기 위한 데이터 패킷을 탐색한다. 만약 시간 내에 찾지 못하면 별도의 패킷을 만들어 전송한다.

TCP 느린 시작

TCP의 전송 속도는 TCP 커넥션이 만들어진지 얼마나 지났는지에 따라 달라질 수 있다. TCP 커넥션은 시간이 지나면서 전송 속도를 계속 변화시키게 되며 처음엔 속도를 제한하다가 점차 속도를 올리게 된다.
이러한 것을 TCP Slow Start라고 하며 이는 급작스러운 부하를 방지하기 위해 쓰인다.
TCP Slow Start는 처음에 커넥션이 맺어질 땐 TCP가 한 번에 전송할 수 있는 패킷의 수를 제한하게 되며 전송이 성공하면 전송 패킷 수를 증가시킨다.
즉 확인 응답을 받을 때마다 전송할 수 있는 패킷 수를 증가시키며 이 때문에 방금 만들어진 TCP 커넥션보다 어느 정도 시간이 지난 TCP 커넥션이 더 빠른 전송 속도를 갖게 된다.
물론 이를 위해서는 커넥션을 유지하도록 만들어야 한다!

네이글(Nagle)알고리즘과 TCP_NODELAY

TCP는 1바이트와 같은 작은 데이터라도 애플리케이션에서 전송할 수 있게 해 주는데, 만약 매번 1바이트의 데이터만 가진 패킷을 보내게 된다면 기본적으로 패킷의 헤더가 40바이트 정도 되기 때문에 매우 비효율적이다. 따라서 효율적인 데이터 정송을 위해 Nagle 알고리즘을 사용하게 되는데, Nagle 알고리즘은 패킷을 전송하기 전에 어느 정도 크기가 될 때까지 모았다가 한 번에 전송하는 알고리즘이다.

하지만 만약 현재 보내는 패킷이 마지막인데도 불구하고 패킷의 크기가 작다고 보내지 않을 경우 영원히 해당 패킷이 전송되지 않을 수 있기 때문에 모든 패킷이 확인 응답을 받았다면 크기가 작다고 해도 패킷을 전송할 수 있게 해 준다. 이러한 부분 때문에 지연이 발생하며 특히 Nagle 알고리즘은 확인 응답 지연과 함께 사용하면 성능이 매우 나빠진다.

따라서 HTTP 애플리케이션은 Nagle 알고리즘을 비활성화할 수도 있는데, 이 때 사용하는것이 TCP_NODELAY이다. 이 값을 사용하면 Nagle 알고리즘을 비활성화 할 수 있습니다.

TIME_WAIT의 누적과 포트 고갈

TIME_WAIT 누적과 포트 고갈은 성능 측정을 할 때는 성능 저하를 보이지만 실제 상황에서는 문제를 발생하지 않는다. TCP 커넥션의 에지에서 TCP 커넥션을 끊으면 에지에서는 커넥션의 IP 주소와 포트번호를 메모리에 기록해둔다. 이렇게 저장해두는 이유는 같은 IP 주소와 포트번호를 사용하는 TCP 커넥션이 일정 시간 동안에는 생성되지 않게 하기 위해서인데, 보통 패킷의 최대 생명주기의 2배(2 MSL이라고 합니다.)인 2분 정도만 유지된다. 만약 이렇게 해주지 않으면 동일한 정보의 새로운 커넥션에 기존에 존재하던 패킷이 삽입되어 패킷이 중복될 수 있고 TCP 데이터가 충돌할 수 있다.

2분 동안 동일한 커넥션을 만들 수 없기 때문에 만약 발신지 포트가 최대 6만개를 사용할 수 있고 2분동안 커넥션이 재사용될 수 없다면 초당 60000 / 120 = 500개의 커넥션이 제한되게 된다. 서버가 초당 500개의 트랜잭션을 처리할 만큼 빠르지 않다면 TIME_WAIT 포트 고갈 문제는 발생하지 않는다. 물론 그렇다고 하더라도 커넥션을 너무 많이 맺거나 커넥션 정보를 메모리에 너무 많이 저장하는 것은 좋지 않기 때문에 주의해야 한다.

HTTP 커넥션 관리

흔히 잘못 이해하는 Connection 헤더

순차적인 트랜잭션 처리에 의한 지연

병렬 커넥션

병렬커넥션은 페이지를 더 빠르게 내려받는다.

병렬 커넥션이 항상 더 빠르지는 않다.

병렬 커넥션은 더 빠르게 '느껴질 수' 있다

병렬(parallel) 커넥션
클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 하여 성능을 개선시킨다.
각 커넥션의 지연 시간이 겹치게 되므로 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는 것이 아니라면 나머지 객체를 내려받는 데에 남은 대역폭을 사용할 수 있다.
병렬 커넥션이 일반적으로 빠르긴 하지만, 클라이언트의 네트워크 대역폭이 좁을 때는 오히려 느려질 수 있다.
다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킬 수 있다.

지속 커넥션

웹 클라이언트는 보통 같은 사이트에 대해 여러 개의 커넥션을 맺는데, 이러한 특징을 사이트 지역성(site locality)라 부른다.
HTTP/1.1 을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다.
처리가 완료된 후에도 연결을 지속하는 상태를 지속 커넥션이라고 한다. 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위한 준비작업에 드는 시간을 절약할 수 있다.

지속 커넥션 vs 병렬 커넥션

병렬 커넥션의 단점

  • 각 트랜잭션마다 새로운 커낵션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
  • 각각의 새로운 커넥션은 TCP의 느린 시작 때문에 성능이 떨어진다.
  • 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다.

지속 커넥션의 장점

  • 사전작업과 지연을 줄여준다.
  • 튜닝된 커넥션을 유지한다.
  • 커넥션의 수를 줄여준다.

병렬 커넥션은 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
각각의 새로운 커넥션은 TCP 느린 시작 때문에 성능이 떨어진다.
실제로 연결할 수 있는 병렬 커넥션 수에는 제한이 있다.

지속 커넥션은 커넥션을 맺기 위한 사전 작업과 지연을 줄여주고, 튜닝된 커넥션을 유지하며, 커넥션 수를 줄여준다.
지속 커넥션을 잘못 관리할 경우, 계속 연결된 상태로 수많은 커넥션이 쌓이게 된다.
지속 커넥션은 병렬 커넥션과 함께 사용될 때 가장 효과적이다.

HTTP/1.0+의 Keep-Alive 커넥션

  • 1996년에 실험적으로 만든 HTTP/1.0의 확장 커넥션으로 설계상 문제가 많이 존재했었다.
  • 이 문제는 추후에 HTTP/1.1에 수정되었다.

Keep-Alive 동작

  • HTTP/1.1 명세에 빠지기는 했지만... 아직도 keep-alive가 널리 사용되고 있다.
  • HTTP/1.0 keep alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청도 Connection:Keep-Alive 헤더를 포함시킨다.
  • 만약에 응답에 Connection: Keep-Alive 헤더가 없다면, 클라리언트는 서버가 Keep-alive를 지원하지 않으며 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정한다.

Keep-Alive 옵션

timeout 커넥션이 얼마간 유지될것인지 유지될것을 의미( 이대로 동작한다는 보장은 없다)
max 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될 것을 의미한다. (이것도 보장 못함)

Keep-Alive 커넥션 제한과 규칙

  1. 모든 메시지에 Connection: Keep-Alive헤더를 추가해야 한다.
    안 그러면 커넥션이 끊겨진다. (클라이언트 서버 모두)
  2. 커넥션이 끊어지기 전에 엔티티 본문의 길이를 알 수 있어야 커넥션을 유지할 수 있다.
    이 말은 엔티티 본문이 정확한 Contnet-Length 값과 함께 멀티파트 미디어 형식을 가지거나 청크 전송 인코딩으로 인코드 되어야 하기 때문이다.
  • keep-alive 커넥션에서 잘못된 Content-Length 값을 보내는 것은 좋지 않은데, 트랜잭션이 끝나는
    시점에 기존 메시지의 끝과 새로운 메시지의 시작점을 정확히 알 수 있어야 한다.
  1. 프락시와 게이트웨이는 Contnention 헤더의 규칙을 철저히 지켜야 한다.
  2. 기술적으로 HTTP/1.0을 따르는 기기로부터 받는 모든 Contention 헤더는 무시해야 한다.
  • 오래된 프락시 서버로 부터 실수로 전달될 수 있기 때문이다.

Keep-Alive와 멍청한(dumb)프락시

Proxy-Connection 살펴보기

HTTP/1.1의 지속 커넥션

지속 커넥션의 제한과 규칙

파이프라인 커넥션

커넥션에 하나의 파이프라인을 설치해서 여러번 호출이 가능하게 만드는 것이다.
어떻게 보면 지속 커넥션과 비슷해보이지만,
다른점은 하나의 트랜잭션 요청이 종료가 되기전에 다른 트랜잭션을 호출이 가능하다는 점이다.
이 파이프라인 커넥션에는 주의점이 존재한다.

1.HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안된다.
2.HTTP 응답은 요청 순서와 같게 와야 한다.
3. HTTP 클라이언트는 커넥션이 언제 끊어지더라도, 완료되지 않은 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어 있어야 한다.
4. HTTP 클라이언트는 POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안된다.
POST같은 메서드를 비멱등 메서드라고 한다.

멱등이란?
연산을 여러번해도 값이 달라지지 않는 성질을 말한다.

그러니까 POST는 여러번 호출하며 결과가 달라진다는 것을 알 수 있다.

커넥션끊기에 대한 미스터리

'마음대로'커넥션 끊기

  • 보통 커넥션은 메시지를 다 보낸 다음 끊지만, 에러가 있는 상황에는 헤더의 중앙이나 다른 엉뚱한 곳에서 끊을 수 있다.
  • 서버가 그 유휴상태에 있는 커넥션을 끊는 지점에, 서버는 클라이언트가 데이터를 전송하지 않을 것이라고 확신하지 못한다.

Content-Length 와 Truncation

  • 각 HTTP응답은 본문의 정확한 크기 값을 가지는 Content-Length 헤더를 가지고 있어야 한다.

커넥션 끊기의 허용, 재시도, 멱등성

  • HTTP 애플리케이션은 예상치 못하게 커넥션이 끊어졌을 때 적절히 대응할 수 있는 준비가 되어 있어야 한다.
  • 비멱등 메서드는 함부로 사용하지 말것!

우아한 커넥션 끊기

  • TCP 커넥션은 양방향이다.
  • TCP 커넥션의 양쪽에는 데이터를 읽거나 쓰기 위한 입력 큐와 출력 큐가 있다.

: 애플리케이션 자신의 출력 채널을 먼저 끊고, 다른 쪽에 있는 출력 채널이 끊기는 것을 기다리는 것 (절반 끊기) 하지만 상대방이 절반끊기를 구현했거나 검사한다는 보장이 없기에 출력 채널을 절반 끊기 한 후에도 데이터나 스트림의 끝을 식별하기 위해 입력 채널에 대해 주기적인 상태검사 필요

reference

https://icksw.tistory.com/222
https://velog.io/@leeinae/HTTP-Connection-TCP
https://icarus8050.tistory.com/130
https://b-programmer.tistory.com/312
https://reakwon.tistory.com/59
https://watrv41.gitbook.io/devbook/web/http/4
https://web-km.tistory.com/17

profile
SeulKing
프론트엔드 개발자 항상 뭘 하고있는 슬킹(seulki + ing)

0개의 댓글