[HTTP 완벽 가이드] 4장. 커넥션 관리

밈무·2023년 1월 26일
네트워크
0

HTTP완벽가이드

목록 보기
4/14

4.1 TCP 커넥션

전세계 모든 HTTP 통신은 TCP/IP를 통해 이루어진다.
일단 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 주고 받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달된다.

http://www.joes.com:80/power-tools.html에서 전동공구의 최신 가격 목록을 가져온다고 가정. 다음과 같은 순서로 진행된다.
1. 브라우저가 www.joes.com이라는 호스트명 추출
2. 브라우저가 이 호스트 명에 대한 ip주소를 찾는다.
3. 브라우저가 포트번호(80)을 얻는다.
4. 브라우저가 202.43.78.3(2에서 얻은 ip주소)의 80포트로 TCP 커넥션을 생성한다.
5. 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다
6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.
7. 브라우저가 커넥션을 끊는다.

4.1.1 신뢰할 수 있는 데이터 전송통로인 TCP

TCP 는 HTTP 에게 신뢰할만한 통신방식을 제공한다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확하게 전달된다. (충돌없이 순서에 맞게 HTTP 데이터를 전달한다.)

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

TCP 는 IP 패킷이라고 불리는 작은 조각을 통해 데이터를 전송한다.

  • HTTP 가 메시지를 전송하려는 경우
    TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아 인터넷을 통해 데이터를 전달한다. 이 모든 것은 TCP/IP 소프트웨어에 의해 처리되며, 각 과정은 HTTP 프로그래머에게 보이지 않는다.
    각 TCP 세그먼트는 하나의 IP주소에서 다른 IP주소로 IP 패킷에 담겨 전달된다.

4.1.3 TCP 커넥션 유지하기

TCP는 포트 번호를 통해 여러개의 커넥션을 유지한다. IP 주소로는 해당 컴퓨터에 연결되고 포트번호로는 컴퓨터 내의 해당 애플리케이션으로 연결되는 것이다.
<발신지 IP주소, 발신지 포트, 수신지 IP주소, 수신지 포트> 이렇게 네가지 값으로 TCP 커넥션을 식별한다. 이 네가지 값으로 유일한 커넥션을 생성하는 것이다. (일부는 겹칠 수 있으나 완벽히 겹칠 수는 없다)

4.1.4 TCP 소켓 프로그래밍

소켓 API는 HTTP 프로그래머에게 TCP 와 IP의 세부사항들을 숨긴다.

4.2 TCP의 성능에 대한 고려

4.2.1 HTTP 트랜잭션 지연

실제 서버에서 트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청 및 응답을 전송하는 시간에 비하면 매우 짧다. 즉, 대부분의 HTTP 지연은 TCP 네트워크 지연에 의해 발생한다.
이런 TCP 네트워크 지연은 하드웨어 성능, 네트워크와 서버의 전송속도, 요청과 응답 메시지의 크기, 클라이언트와 서버간의 거리에 따라 크게 달라진다. TCP 프로토콜의 기술적인 복잡성도 지연에 큰 영향을 미친다.

4.2.2 성능 관련 중요 요소

  • TCP 커넥션의 핸드셰이크 설정
  • 인터넷의 혼잡을 제어하기 위한 TCP 의 느린 시작(slow-start)
  • 데이터를 한데 모아 한번에 전송하기 위한 네이글(nagle) 알고리즘
  • TCP 의 편승(piggyback) 확인응답(acknowledgement)을 위한 확인 응답 지연 알고리즘
  • TIME_WAIT 지연과 포트 고갈

4.2.3 TCP 커넥션 핸드셰이크 지연

  • TCP 커넥션 핸드셰이크 과정
    1. 클라이언트가 새로운 TCP 커넥션을 생성하기 위해 SYN 패킷을 서버에게 보낸다. (커넥션 생성요청)
    2. 서버가 그 커넥션을 받으면 SYN+ACK이 포함된 패킷을 클라이언트에게 보낸다. (커넥션 요청 받아들이고 요청 맺을게)
    3. 클라이언트가 커넥션이 잘 맺어졌음을 알리기 위해 서버에게 다시 ACK을 보낸다. 오늘날의 TCP 는 클라이언트가 이 확인 응답 패킷과 함께 데이터를 보낼 수 있다.

작은 크기의 데이터 전송에 커넥션이 사용된다면 이런 패킷 교환이 HTTP 성능을 크게 저하시킬 수 있다.
SYN/SYN+ACK 핸드셰이크(1,2)가 눈에 띄는 지연을 발생시킨다. TCP의 ACK 패킷은 HTTP 요청메시지 전체를 전달할 수 있을 만큼 큰 경우가 많고, 많은 HTTP 서버 응답 메시지는 하나의 IP 패킷에도 담길 수 있는 경우가 많기 때문이다.
결국 크기가 작은 HTTP 트랜잭션은 50퍼센트 이상의 시간을 TCP를 구성하는 데에 쓴다.
=> HTTP 에서 커넥션을 재활용하는 이유1

4.2.4 확인응답 지연으로 인한 지연

인터넷 자체가 패킷 전송을 완벽하게 보장하지는 않기 때문에 TCP 는 성공적인 데이터 전송을 보장하기 위해 자체적인 확인 체계를 가진다.
TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가지고 각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다.(이를 받지 못하면 문제가 있는 것으로 판단하고 데이터를 다시 전송한다)

이때 데이터 패킷에 확인응답을 편승(piggyback)시킬 수 있다. 그렇게 해서 네트워크를 좀더 효율적으로 사용한다.
이렇게 편승될 수 있는 경우를 늘리기 위해 많은 TCP 스택은 확인 응답 지연 알고리즘을 구현한다. 특정시간동안 확인응답을 버퍼에 저장해두고 편승할 송출 데이터 패킷을 찾는 것이다. 만약 찾지 못하면 그냥 확인응답만 보낸다.

그런데 막상 데이터 패킷이 찾아지는 경우가 많지 않기 때문에 오히려 확인응답 지연 알고리즘으로 인해 더 지연이 발생한다. 그래서 운영체제에서 확인 응답 지연 관련 기능을 수정하거나 비활성화할 수 있게 한다.

4.2.5 TCP의 느린 시작(slow start)로 인한 지연

TCP 커넥션은 시간이 지나면서 점차 자체적으로 튜닝하여 커넥션의 최대 속도를 늘려가는 특징이 있다.(TCP 커넥션 튜닝)
그래서 TCP 커넥션은 처음 맺어졌을 때 속도가 가장 느리고 이것을 TCP의 slow start라고 부른다. 이는 인터넷의 급작스러운 부하와 혼잡을 방지(혼잡제어)하기 위해 TCP 가 한번에 전송할 수 있는 패킷의 수를 제한하는 것이다. 패킷이 성공적으로 전달되는 각 시점에 송신자는 추가로 2개의 패킷을 더 전송할 수 있는 권한을 얻는 식으로 작동한다. (혼잡윈도를 연다)

즉 새로운 커넥션보다 튜닝된 커넥션이 더 빠르다.
=> HTTP 에서 커넥션을 재활용하는 이유2

4.2.6 네이글(Nagle)알고리즘과 TCP_NODELAY로 인한 지연

TCP 세그먼트는 40바이트 상당의 플래그와 헤더를 포함하여 전송하기 대문에 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다.

네이글 알고리즘은 네트워크 효율을 위해 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한개의 덩어리로 합친다.

  • 세그먼트가 최대 크기일 때
  • 전송되고 나서 확인응답을 기다리던 패킷이 모두 확인응답을 받았을 때
    의 경우에 전송을 허락한다.

이는 HTTP 성능을 저하시킨다.

  • 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연되어야 한다.
  • 특히 확인응답 지연과 함께 쓰이게 되면 네이글알고리즘은 확인 응답이 도착할 때까지 데이터를 전송하지 않고, 확인 응답 지연 알고리즘은 확인 응답을 100-200밀리초를 지연시키기 때문이다.

따라서 네이글 알고리즘을 비활성화하기도 하는데 그럴 경우 작은 크기의 패킷이 너무 많이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 한다.

4.2.7 TIME_WAIT의 누적과 포트 고갈

TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역(control block)에 기록해둔다. (커넥션 종료 지연)
이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안 생성되지 않게 하기 위한 것으로, 이 시간을 TIME_WAIT 라고 한다.
(보통 세그먼트의 최대 생명 주기의 2배 정도로 설정되며 2분정도(2MSL))

TIME_WAIT 사용 이유

  1. 지연 패킷이 새로운 커넥션에 끼어드는 것을 막을 수 있다.

    TIME_WAIT을 사용하면 이전 커넥션의 지연 패킷이 새로운 커넥션에 삽입되는 문제를 방지할 수 있다.
    매우 드문 경우이긴 하지만, SEQ=3의 패킷이 지연된 후 새로운 커넥션이 생성되었고, 때마침 해당 커넥션에 SEQ=3이 들어올 타이밍이었다면 데이터 무결성 문제가 발생할 수 있다.
  2. LAST_ACK가 유실된 경우를 막을 수 있다.

    위 사진처럼 마지막 ACK가 유실된 경우, 상대는 LAST_ACK 상태에 빠지고, 새로운 커넥션이 SYN 패킷 전달시 RST를 리턴한다.
    따라서 반드시 TIME_WAIT이 일정 시간 남아있어서 패킷의 오동작을 막아야 한다.

이런 커넥션 종료 지연은 평상시에는 큰 문제가 되지 않지만 부하 테스트 상황에서는 문제가 될 수 있다.

4.3 HTTP 커넥션 관리

4.3.1 흔히 잘못 이해하는 Connection 헤더

HTTP 메시지는 클라이언트에서 중개서버(사이의 프락시서버, 캐시 서버 등)들을 거쳐 서버에게 전달된다.

  • Connection 헤더의 값들로는 다음의 3가지 정보가 전달될 수 있다.
    • HTTP 헤더필드 명 : 홉과 홉 사이에서만 사용하므로 그 다음 홉으로 넘겨줘서는 안될 헤더
    • close 값 : 작업이 안료되면 커넥션이 종료되어야 함을 의미
    • 임시적인 토큰 값 : 커넥션에 대한 비표준 옵션을 의미
HTTP/1.1 200 OK
Cache-control: max-age=3600
Connection: meter, close, bill-my-credit-card
Meter: max-uses=3, max-refuses=6, dont-reportCopy

👆 이 메시지에서 Connection 헤더는, Meter 헤더를 다른 커넥션으로 전달하면 안 되고, bill-my-credit-card 옵션을 적용할 것이며, 이 트랜잭션이 끝나면 커넥션이 끊길 것이라는 뜻.

HTTP 애플리케이션이 Connection 헤더와 함께 메시지 전달 받으면, 수신자는 송신자에게서 온 요청에 기술되어 있는 모든 옵션을 적용하고 다음 홉(서버)에 전달하기 전에 Connection 헤더와 기술되어 있던 모든 헤더들을 삭제한다. 즉, 특정 서버 간에만 영향을 미치고 다른 서버 간에는 영향을 미치지 않는다.

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

커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아질 수 있다.

3개의 이미지가 있는 웹페이지. 브라우저가 이 페이지를 보여주려면 네 개의 HTTP 트랜잭션을 만들어야 한다. (1개는 해당 HTML, 나머지 세 개는 이미지를 받기 위해). 각 트랜잭션이 새로운 커넥션을 사용(순차적인 트랜잭션 처리)한다면, 커넥션을 맺는 데 발생하는 지연과 함께 느린시작이 발생할 것이다.

순차적으로 로드되면 사용자에게 높은 응답성을 제공할 수 없다.(하나의 이미지를 내려받고 있는 중에는 웹 페이지 나머지 공간에는 아무런 변화가 없다. 심지어 어떤 브라우저의 경우 객체의 크기를 알아야 화면에 배치할 수 있기 때문에 모든 객체를 다 내려받기 전까지는 텅 빈 화면 제공)

HTTP 커넥션의 성능을 향상시킬 수 있는 기술 4가지

  • 병렬(Parallel) 커넥션
    여러개의 TCP 커넥션을 통한 동시 HTTP 요청
  • 지속(Persistent) 커넥션
    커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용
  • 파이프라인(pipeline) 커넥션
    공유 TCP 커넥션을 통한 병렬 HTTP 요청
  • 다중(multiplexed) 커넥션
    요청과 응답들에 대한 중재(실험적인 기술)

4.4 병렬 커넥션

클라이언트가 여러 개의 커넥션을 맺어 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다. (각각의 HTTP 커넥션에서 웹 페이지의 컴포넌트 병렬적으로 처리)

여러 개의 커넥션을 생성해 동시에 내려 받으면서, 각 커넥션의 지연을 겹치게 할 수 있어 총 지연 시간을 줄일 수 있다.

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

  • 대역폭이 좁은 경우 성능 상의 장점이 거의 없어진다. 실제로는 여러 개의 커넥션을 생성하면서 생기는 부하 때문에 객체들을 순차적으로 내려받는 것보다 더 오래 걸릴 수도 있다.
  • 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킨다.
  • 브라우저는 실제로 병렬 커넥션을 사용하긴 하지만 적은 수(6~8)의 병렬 커넥션만을 허용한다.

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

병렬 커넥션이 페이지를 더 빠르게 내려받는 것은 아니지만, 화면에 여러 개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있기 때문에 사용자는 더 빠르게 내려받고 있는 것처럼 느낄 수 있다.

4.5 지속 커넥션

웹 클라이언트는 보통 같은 사이트에 여러 개의 커넥션을 맺는다.
사이트 지역성(site locality)은 서버에 HTTP 요청을 하기 시작한 애플리케이션이 웹페이지 내의 이미지 등을 가져오기 위해 그 서버에 또 요청하는 것을 말한다. (한 웹페이지를 모두 보여주려면 같은 서버에서 요청을 주고 받아야 한다는 말인 듯)
따라서 HTTP/1.1을 지원한다면 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 이렇게 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라 한다.

=> 커넥션을 맺기 위한 준비 작업에 따르는 시간을 절약하고, 이미 맺어진 커넥션은 느린 시작으로 인한 지연이 없기 때문에 더 빠르게 데이터를 전송할 수 있다.

4.5.1 지속 커넥션 vs 병렬 커넥션

  • 병렬 커넥션의 단점
    • 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
    • 각각의 새로운 커넥션은 TCP 느린시작 때문에 성능이 떨어진다.
    • 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다.
  • 지속 커넥션의 장점(병렬 커넥션과 비교해서)
    • 커넥션을 맺기 위한 사전 작업과 지연을 줄여준다.
    • 튜닝된 커넥션을 유지한다.(느린시작으로 인한 지연이 없다는 것)
    • 커넥션의 수를 줄여준다.

하지만 지속커넥션을 잘못 관리하면 계속 연결된 상태로 있는 수많은 커넥션이 쌓여 로컬의 리소스와 원격의 클라이언트와 서버의 리소스에 불필요한 소모를 발생시킨다.

따라서 지속 커넥션과 병렬 커넥션을 함께 사용할 때 가장 효과적이다. 오늘날의 많은 웹 애플리케이션은 적은 수의 병렬 커넥션만을 맺고 그것을 유지한다.

다음부턴 두가지 지속 커네션의 타입에 대해 알아본다.

4.5.2 HTTP/1.0+의 Keep-Alive 커넥션

  • 장점
    • 커넥션을 맺고 끊는 데 필요한 작업이 없어 시간 단축
    • 느린 시작으로 인한 지연이 없어 시간 단축

4.5.3 Keep-Alive 동작

keep-alive는 사용하지 않기로 결정되어 HTTP/1.1 명세에서 빠졌으나 아직도 이 핸드셰이크가 널리 사용되고 있기 때문에 이를 처리할 수 있도록 개발해야 한다.
메시지에 Connection: Keep-Alive 헤더를 포함시켜야 한다.

4.5.4 Keep-Alive 옵션

Keep-Alive 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다. 언제든지 끊을 수 있고 keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수도 있다.

  • timeout 파라미터 : 커넥션이 얼마나 유지될지 의미. 그러나 이대로 동작 보장은 x
  • max 파라미터 : 몇개의 트랜잭션을 처리할 때까지 커넥션 유지할지. 그러나 이대로 동작 보장은 x
Connection : Keep-Alive
Keep-Alive : max=5, timeout=120

4.5.5 Keep-Alive 커넥션 제한과 규칙

  • HTTP/1.0에서 기본 X. 클라이언트가 Connection: Keep-Alive 요청 헤더를 보내야 한다.
  • 커넥션 계속 유지하려면 모든 메시지에 Connection :Keep-Alive 헤더를 보내야 한다.
  • 트랜잭션이 끝나는 시점에 기존 메시지의 끝과 새로운 메시지의 시작점을 정확히 하기 위해 엔터티 본문이 정확한 Content-Length와 multipart media type을 가지거나 청크 전송 인코딩으로 인코드되어 있어야 한다.

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

Connection 헤더의 무조건 전달

문제는 특히 프락시에서 시작된다. 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달한다. 하지만 Connection 헤더는 hop-by-hop헤더이기 때문에 문제가 발생한다. 홉별 헤더를 전달받은 서버가 그 헤더를 자신과 프락시 간의 커넥션에 대한 것으로 오해하기 때문이다.
웹 클라이언트가 멍청한 프락시(무조건 전달함)를 거쳐 웹서버에 메시지를 전송하면 웹 클라이언트와 웹 서버는 커넥션을 유지하는 것으로 알고 있지만 프락시는 그렇지 않다. 그렇게 되면 프락시는 계속 커넥션이 끊어지길 기다리고 있고 같은 커넥션 상에서 다른 요청이 오는 경우를 예상하지 못해 클라이언트가 새롭게 보낸 요청은 프락시로부터 무시되고 브라우저는 아무런 응답없이 로드 중 표시만 나온다.
=> 브라우저는 자신이나 서버가 타임아웃이 나서 커넥션이 끊길 때까지 기다려야 한다.

프락시와 홉별 헤더

이런 잘못된 통신을 피하기 위해선 프락시는 Connection 헤더와 Connection 헤더에 명시된 헤더를 절대 전달하면 안 된다.

4.5.7 Proxy-Connection 살펴보기

위의 문제를 해결하기 위한 차선책으로 클라이언트의 요청이 중개서버를 통해 이어지는 경우 모든 헤더를 무조건 전달하는 문제를 해결하기 위해 Proxy-Connection이라는 헤더를 사용하는 방법이 있다.

  • 멍청한 프락시인 경우
    프락시는 Proxy-Connection 헤더를 무조건 전달하지만 웹서버가 그것을 무시하기 때문에 문제 발생 x -> 그냥 keep-alive 커넥션이 맺어지지 않음
  • 영리한 프락시인 경우
    Proxy-Connection 헤더를 인식하고 Connection: Keep-Alive 헤더로 바꿔서 보낸다.

그런데 이 방법은 서버 사이 한 개의 프락시가 있는 경우에서만 작동한다. 멍청한 프락시 옆에 영리한 프락시가 있으면 다시 헤더를 잘못 만들어내는 문제가 발생한다.

4.5.8 HTTP/1.1의 지속 커넥션

HTTP/1.1은 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원한다. 목적은 같지만 더 잘 동작한다.

  • 기본으로 활성화 (끊으려면 Connection: close 헤더 명시) (이전 HTTP 프로토콜과 큰 차이점)
  • 그렇다고 해서 Connection: close가 없다고 영원히 커넥션이 유지된다는 것은 아님. 언제든지 커넥션을 끊을 수 있다.

4.5.9 지속 커넥션의 제한과 규칙

4.6 파이프라인 커넥션

HTTP/1.1은 지속 커넥션을 통해 요청을 파이프라이닝 할 수 있는데 이는 keep-alive 커넥션의 성능을 더 높여준다.
지속커넥션은 TCP 커넥션 지연을 제거(커넥션이 새로 생기는 데 걸리는 시간 단축)하고 파이프라인은 전송 대기시간을 단축한다. (여러개의 요청이 응답이 도착하기 전까지 큐에 쌓이고, 요청들을 이어서 전달할 수 있다)

  • 제약사항
    • 지속커넥션인지 확인하고 파이프라인을 이어야 한다.
    • 응답은 요청 순서와 같아야 한다. (HTTP 메시지에 순번이 없기 때문)
    • 클라이언트는 예상치 못하게 끊긴 커넥션을 다시 맺고 요청을 보낼 수 있어야 한다. (다 안 보냈는데 서버가 끊어버릴 수 있음)
    • 비멱등 요청(POST)을 재차 보내면 문제발생 할 수 있음. 에러가 발생하면 파이프라인을 통한 요청 중에 어떤 것들이 서버에서 처리되었는지 클라이언트가 알 수 없다.

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

커넥션 관리에는 명확한 기준이 없다.

4.7.1 '마음대로'커넥션 끊기

HTTP 클라이언트, 서버, 프락시 모두 마음대로 언제든지 TCP 전송 커넥션을 끊을 수 있다. 보통 커넥션은 메시지를 다 보낸 다음 끊지만(서버는 클라이언트나 네트워크 실패가 의심되지 않는다면 응답 중간에 커넥션을 끊으면 안된다) 에러가 있는 상황에서는 헤더의 중간이나 다른 엉뚱한 곳에서 끊길 수 있다.

파이프라인 지속 커넥션에서도 마찬가지.

예를 들어 지속커넥션이 일정시간동안 요청을 전송하지 않으면 서버는 그 커넥션을 끊을 수 있다. (요청메시지 전송도중 끊기면 문제 발생)

4.7.2 Content-Length 와 Truncation

각 HTTP 응답은 Content-Length 헤더를 가지고 있어야 한다.

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

  • 멱등 : 여러 번 실행해도 같은 결과를 반환 (GET, HEAD, PUT, DELETE, TRACE, OPTIONS

이런 멱등이 아닌 POST와 같은 메소드는 파이프라인을 통해 요청하면 안된다. 그렇지 않으면 전송 커넥션이 예상치 못하게 끊어져 버렸을 때 알 수 없는 결과를 초래할 수 있다. 비멱등인 요청을 다시 보내야 한다면 (커넥션이 도중에 끊겨서) 이전 요청에 대한 응답을 받을 때까지 기다려야 한다.(아직 응답이 오기 전에 커넥션이 끊겼었다면 클라이언트는 실제로 서버에서 얼만큼 요청이 처리되었는지 알 수 없으니까)

4.7.4 우아한 커넥션 끊기

TCP 커넥션은 양방향

전체 끊기와 절반 끊기

  • 전체 끊기 : TCP 커넥션의 입력 채널과 출력 채널의 커넥션을 모두 끊음(close())
  • 절반 끊기 : 입력 채널이나 출력 채널 중에 하나를 개별적으로 끊음(shutdown())
    • 서버 출력 절반 끊기(우아햔 커넥션 끊기)
    • 서버 입력 절반 끊기
profile
밈무
이전 포스트

[HTTP 완벽 가이드] 3장. HTTP 메시지

다음 포스트

[HTTP 완벽 가이드] 5장. 웹 서버

0개의 댓글