04_Connection_Management.md

04장 🐙 커넥션 관리

📄 퀴즈해설 바로가기

4.1　TCP 커넥션

4.2　TCP의 성능에 대한 고려

4.3　HTTP 커넥션 관리

4.4　병렬 커넥션

4.5　지속 커넥션

4.6　파이프라인 커넥션

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

4.1 　 TCP 커넥션　 taelee

1. 다음은 '죠의 컴퓨터 가게에서 전동공구의 목록'을 가져올 때 생성되는 TCP 커넥션 과정이다. 빈칸에 알맞은 답을 보기에서 찾아 채워넣어보자

• 보기(안쓰이는 보기도 있음)

  포트번호(80), TCP 커넥션, GET 요청, HEAD 요청, HTTP 커넥션, 도메인 네임, IP 주소

1. 브라우저가 www.joes-hardware.com라는 호스트 명을 추출한다.

2. 브라우저가 이 호스트 명에 대한 (a. _______ )을/를 찾는다.

3. 브라우저가 (b. _______ )을/를 얻는다.

4. 브라우저가 202.43.78.3의 80포트로 (c. _______ )을 생성한다.

5. 브라우저가 서버로 HTTP (d. _______ ) 메시지를 보낸다.

6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.

7. 브라우저가 커넥션을 끊는다.

2. 다음 보기를 이용해서 HTTPS의 프로토콜 스택을 만들어 보자

• HTTP, Network Interfaces, TLS or SSL, TCP

  a)_____________	애플리케이션 계층
  b)_____________	보안 계층
  c)_____________	전송 계층
  IP	네크워크 계층
  d)_____________	데이터 링크 계층

3. TCP 커넥션은 발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트 로만 이루어져 있다. ( O | X )

4. TCP 커넥션의 4가지 구성요소가 같다면 서로 같은 TCP 커넥션이다. 따라서 서로 다른 TCP 커넥션은 공통된 구성요소를 공유하지 않는다. ( O | X )

5. 소켓 프로그래밍에서 서버소켓은 클라이언트 소켓이 연결을 시도하면 생성된다. ( O | X )

📄 답지

4.2 　 TCP의 성능에 대한 고려　 yeosong

HTTP가 TCP 바로 윗 계층이므로, HTTP 트랜잭션의 성능을 논할 때 TCP 성능을 고려할 필요가 있다.

4.2.1 HTTP 트랜잭션 지연

트랜잭션이란?

• 하나의 논리적 기능을 수행하기 위한 작업의 단위
• 작업의 완전성을 보장함
  • 성공시 커밋
  • 실패시 롤백(방금 수행 실패한 트랜잭션을 이전 상태로 되돌리고, 재시도 혹은 폐기함.)
• HTTP transaction 1개는 1개의 HTTP request와 그에 상응하는 HTTP response로 이루어져있다.

• HTTP 지연은 클라이언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행할 때 생긴다. (O/X)
• HTTP 지연의 대부분은 TCP 네트워크 지연 때문에 생긴다. (O/X)
• TCP 네트워크의 지연 정도는 요청/응답 메시지의 크기, 클라이언트와 서버간의 거리에 따라서도 달라진다. (O/X)

4.2.2 성능 관련 중요 요소

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

• 아주 큰 데이터를 주고받지 않는 평범한 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는 데 쓴다. (O/X)
• TCP 구성으로 인한 지연을 제거하기 위해 이미 존재하는 커넥션을 재활용하기도 한다. (O/X)

4.2.4 확인응답 지연

• TCP는 성공적인 데이터 전송을 보장하기 위해 확인응답 패킷을 사용한다. (O/X)
• '확인응답 지연' 알고리즘은 확인응답 패킷을 잠시 버퍼에 둔 채로 편승(piggyback)할 수 있는 데이터 패킷 찾는 알고리즘이다. (O/X)

4.2.5 TCP 느린 시작(slow start)

• 인터넷의 급작스러운 부하와 혼잡을 방지하기 위하여 커넥션의 최대 속도를 제한하여 점차 높여 나가는 것을 'silly window syndrome'이라고 부른다. (O/X)
• 패킷이 성공적으로 전달되는 각 시점에 송신자는 추가로 4개의 패킷을 더 전송할 수 있는 권한을 얻는다. (O/X)
• 새로운 커넥션은 항상 튜닝된 커넥션보다 빠르다 (O/X)

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

• 네이글 알고리즘은 네트워크의 효율을 위해 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합치는 알고리즘이다. (O/X)
• 네이글 알고리즘은 작은 메시지의 경우 패킷을 채우지 못해 기다리며 지연되는 단점이 있는데, 확인응답 지연 알고리즘과 함께 사용하면 이를 보완할 수 있다. (O/X)
• 네이글 알고리즘은 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하면 비활성화 시킬 수 있다. (O/X)

4.2.7 TIME_WAIT의 누적과 포트 고갈

• TIME_WAIT 포트 고갈은 실제 상황에서는 문제를 발생시키지 않는다. (O/X)
• 2MSL은 2분을 의미한다. (O/▲/X)

📄 답지

4.3 　 HTTP 커넥션 관리　 hylee

1. Connection 헤더는 세 가지 종류의 토큰(HTTP 헤더 필드 명, 임시적인 토큰 값, close 값)을 전달받아 전송자가 목적지까지의 모든 커넥션에 원하는 옵션을 지정하게 해준다. (O/X)
2. HTTP 애플리케이션이 Connection 헤더와 함께 메시지를 전달받은 후 다음 홉(hop)에 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있는 모든 헤더들을 삭제할 뿐 아니라 Connection 헤더에 기술되어 있지 않는 홉별 헤더들도 삭제해서 전달한다. (O/X)
3. 순차적인 트랜잭션 처리로 인한 지연에는 물리적인 지연 뿐 아니라, 하나의 이미지를 내려받고 있는 중에 웹페이지의 나머지 공간에 아무런 변화가 없어서 느껴지는 _________ 인 지연 도 있다.

📄 답지

4.4 　 병렬 커넥션　 hylee

1. 병렬 커넥션 방식을 이용하여 3개의 이미지가 있는 웹페이지를 브라우저가 보여줄 때 4개의 트랜잭션이 각각 별도의 커넥션에서 동시에 처리되어진다. (O/X)
2. 병렬 커넥션은 단일 커넥션보다 항상 더 빠르지 않다 (O/X)

📄 답지

4.5 　 지속 커넥션　 yeha

1. 지속 커넥션에 대한 설명으로 거리가 먼 것을 모두 고르세요. (____)
   (1) 요청에 대한 처리가 완료된 후 TCP 커넥션을 유지하며 앞으로 있을 HTTP 요청에 재사용한다.
   (2) 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지한다.
   (3) TCP의 느린 시작으로 인한 지연을 피함으로써 대역폭은 소요되지만 시간을 절약할 수 있다.
   (4) 수많은 커넥션이 계속 연결된 상태로 쌓이게 되면 불필요한 소모가 발생한다.
   (5) 병렬 커넥션과 함께 사용하면 효과적이다.

2. 초기 keep-alive 커넥션에 대한 설명으로 거리가 먼 것을 모두 고르세요. (___)
   (1) 초기 keep-alive 커넥션은 상호 운용과 관련된 설계에 문제가 있었다.
   (2) 아직까지 많은 클라이언트와 서버에서 사용되고 있다.
   (3) (1)에서 언급한 설계상의 문제는 수정되지 않았다.

3. keep-alive에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) HTTP/1.0에서 기본으로 사용되지는 않는다. (O/X)
   (2) HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해 요청에 Connection:Keep-Alive 헤더를 반드시 포함시켜야 한다. (O/X)
   (3) (1)의 요청을 받은 서버는 응답 메세지에 반드시 같은 헤더를 포함시켜서 응답해야 한다. (O/X)
   (4) 클라이언트나 서버는 keep-alive 요청을 받을 시 keep-alive 커넥션을 유지한다. (O/X)
   (5) keep-alive 응답 헤더를 통해 보내는 옵션 (timeout, max 파라미터 ..)는 지정한 대로 동작된다. (O/X)
(6) 커넥션이 끊어지기 전 엔터티 본문의 길이를 알아야 커넥션을 유지할 수 있다. (O/X)
   (7) 프락시와 게이트웨이는 Connection 헤더의 규칙을 철저하게 지켜야 한다. (O/X)

4. HTTP/1.1의 지속 커넥션에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) HTTP/1.1에서는 keep-alive 커넥션과 설계가 더 개선된 지속 커넥션을 지원한다. (O/X)
   (2) 별도 설정을 하지 않는 한 모든 커넥션을 지속 커넥션으로 취급한다. (O/X)
   (3) 커넥션을 끊으려면 헤더를 포함시키지 않은 요청/응답을 보내면 된다. (O/X)
   (4) HTTP/1.1 애플리케이션은 중간에 끊어지는 커넥션을 복구할 수 있어야 한다. (O/X)

5. Proxy-Connection 헤더에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) 영리한 프락시는 의미 없는 비표준 Proxy-Connection 확장 헤더를 Connection 헤더로 바꾸어 전달한다. (O/X)
   (2) 멍청한 프락시는 Proxy-Connection 헤더 역시 무조건 전달하지만 웹 서버가 무시하기 때문에 문제가 되지 않는다. (O/X)

📄 답지

4.6 　 파이프라인 커넥션　 kukim

1. http 클라이언트는 지속커넥션 여부와 상관없이 파이프라인을 연결할 수 있다.(O/X)
2. http 클라이언트는 지속 커넥션 응답에 대해 요청 순서와 상관없이 Content-Length을 통해 정렬하여 해석할 수 있다. (O/X)
3. http 지속 커넥션의 요청에 대한 서버의 응답 메세지가 어떠한 오류로 끊어지더라도 서버에서 이를 기억하여 다시 보내준다. (O/X)
4. 모든 메서드는 파이프라인 커넥션을 사용할 수 있다. (O/X)
5. (+a) 현재 HTTP/1.1 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어 사용되고 있다. (O/X)

📄 답지

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

1. HTTP 커넥션은 반드시 메세지를 다 보낸 후 종료된다. (O/X)
2. Content-Length 헤더의 역할은 무엇인가? (주관식)
3. HTTP/1.1 명세에서 언제, 어떻게 커넥션을 끊는가에 대한 명확한 기준이 정해져있다. (O/X)
4. 우아하게

• ‘우아하게 커넥션을 끊는 방법 중’ 클라이언트가 예기치 않은 상황에서 커넥션을 끊어야 할 때 절반 끊기 중 (입력/출력 채널)을 끊는다.
• 절반 끊기 (입력/출력 채널)을 끊은 후 우아하게 기다린다. (O/▲/X)

📄 답지

---

📄 정답 및 해설

4.1 　 TCP 커넥션　 taelee

1. 다음은 '죠의 컴퓨터 가게에서 전동공구의 목록'을 가져올 때 생성되는 TCP 커넥션 과정이다. 빈칸에 알맞은 답을 보기에서 찾아 채워넣어보자

• 보기(안쓰이는 보기도 있음)

  포트번호(80), TCP 커넥션, GET 요청, HEAD 요청, HTTP 커넥션, 도메인 네임, IP 주소

1. 브라우저가 www.joes-hardware.com라는 호스트 명을 추출한다.

2. 브라우저가 이 호스트 명에 대한 (a. IP 주소 )을/를 찾는다.

3. 브라우저가 (b. 포트번호(80) )을/를 얻는다.

4. 브라우저가 202.43.78.3의 80포트로 (c. TCP 커넥션 )을 생성한다.

5. 브라우저가 서버로 HTTP (d. GET 요청 ) 메시지를 보낸다.

6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.

7. 브라우저가 커넥션을 끊는다.

2. 다음 보기를 이용해서 HTTPS의 프로토콜 스택을 만들어 보자

• HTTP, Network Interfaces, TLS or SSL, TCP

  a) HTTP	애플리케이션 계층
  b) TLS or SSL	보안 계층
  IP	전송 계층
  c) TCP	네크워크 계층
  d) Network Interfaces	데이터 링크 계층

3. TCP 커넥션은 발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트 로만 이루어져 있다. ( O )

4. TCP 커넥션의 4가지 구성요소가 같다면 서로 같은 TCP 커넥션이다. 따라서 서로 다른 TCP 커넥션은 공통된 구성요소를 공유하지 않는다. ( X )

• 공통된 구성요소를 갖고 있어도 모든 요소가 갖지 않으면 서로 다른 TCP커넥션이다.

5. 소켓 프로그래밍에서 서버소켓은 클라이언트 소켓이 연결을 시도하면 생성된다. ( X )

• 서버 소켓은 클라이언트 소켓의 요청을 받기 전에 미리 생성(Create)되고 포트번호와 묶인(Bind) 뒤 클라이언트로부터의 연결을 주시(Listen)하고 있어야한다.

📝 문제

4.2 　 TCP의 성능에 대한 고려　 yeosong

• 트랜잭션 설명 참고한 페이지

4.2.1 HTTP 트랜잭션 지연

• HTTP 지연은 클라이언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행할 때 생긴다. (O)
• HTTP 지연의 대부분은 TCP 네트워크 지연 때문에 생긴다. (O)
• TCP 네트워크의 지연 정도는 요청/응답 메시지의 크기, 클라이언트와 서버간의 거리에 따라서도 달라진다. (O)

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

• 아주 큰 데이터를 주고받지 않는 평범한 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는 데 쓴다. (O)
• TCP 구성으로 인한 지연을 제거하기 위해 이미 존재하는 커넥션을 재활용하기도 한다. (O)

4.2.4 확인응답 지연

• TCP는 성공적인 데이터 전송을 보장하기 위해 확인응답 패킷을 사용한다. (O)
• '확인응답 지연' 알고리즘은 확인응답 패킷을 잠시 버퍼에 둔 채로 편승(piggyback)할 수 있는 데이터 패킷 찾는 알고리즘이다. (O)

4.2.5 TCP 느린 시작(slow start)

• 인터넷의 급작스러운 부하와 혼잡을 방지하기 위하여 커넥션의 최대 속도를 제한하여 점차 높여 나가는 것을 'silly window syndrome'이라고 부른다. (X)
  • TCP 느린 시작이라고 한다.
  • silly window syndrome 전송자는 1바이트 크기의 패킷을 대량으로 전송하는 비효율적, 반사회적인 전송자를 말한다.
• 패킷이 성공적으로 전달되는 각 시점에 송신자는 추가로 4개의 패킷을 더 전송할 수 있는 권한을 얻는다. (X)
  • 2개씩 늘어난다. 이를 'congestion window를 연다'고 말한다.
• 새로운 커넥션은 항상 튜닝된 커넥션보다 빠르다 (X)
  • TCP는 언제나 느린 시작을 하므로, 느린 시작 이후 튜닝된 커넥션이 언제나 새로운 커넥션보다 빠르다.

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

• 네이글 알고리즘은 네트워크의 효율을 위해 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합치는 알고리즘이다. (O)
• 네이글 알고리즘은 작은 메시지의 경우 패킷을 채우지 못해 기다리며 지연되는 단점이 있는데, 확인응답 지연 알고리즘과 함께 사용하면 이를 보완할 수 있다. (X)
  • 97p 함께 쓰일 경우 형편없이 동작한다. 네이글은 확인응답을 기다리고, 확인응답 지연은 확인응답을 지연시킨다.
• 네이글 알고리즘은 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하면 비활성화 시킬 수 있다. (O)

4.2.7 TIME_WAIT의 누적과 포트 고갈

• TIME_WAIT 포트 고갈은 실제 상황에서는 문제를 발생시키지 않는다. (O)
  • 98p '서버가 초당 500개 이상의 트랜잭션을 처리할 만큼 빠르지 않다면 TIME_WAIT 포트 고갈은 일어나지 않는다. 이 문제를 해결하기 위해 ... 를 쓸 수도 있다.'
• 2MSL은 2분을 의미한다. (▲)
  • 흔히 2분이라고 하긴 한다.
  • 2MSL이란 Maximum Segment Lifetime(=세그먼트의 최대 생명주기)의 2배를 말한다.
  • 라우터가 느렸던 때에 커넥션을 마친 패킷이 살아있는 시간이 약 1분이여서, 그걸 2배 해서 = 2분이었다.
  • 현재는 2MSL = 1 ~ 4분이며 운영체제에 따라 다를 수 있고, 이 값은 조정이 가능하다.

📝 문제

4.3 　 HTTP 커넥션 관리　 hylee

1. Connection 헤더는 세 가지 종류의 토큰(HTTP 헤더 필드 명, 임시적인 토큰 값, close 값)을 전달받아 전송자가 목적지까지의 모든 커넥션에 원하는 옵션을 지정하게 해준다.

• 정답 : X
  • 3가지 종류의 토큰은 맞는데 Connection 헤더는 전송자가 특정 커넥션에만 해당되는 옵션을 지정하게 해준다. (p. 99, 100)

1. HTTP 애플리케이션이 Connection 헤더와 함께 메시지를 전달받은 후 다음 홉(hop)에 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있는 모든 헤더들을 삭제할 뿐 아니라 Connection 헤더에 기술되어 있지 않는 홉별 헤더들도 삭제해서 전달한다.

• 정답 : O
  • 홉별 헤더들 역시 전달하거나 캐시하면 안 된다. ex) Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade (p. 99, 110)

1. 순차적인 트랜잭션 처리로 인한 지연에는 물리적인 지연 뿐 아니라, 하나의 이미지를 내려받고 있는 중에는 웹페이지의 나머지 공간에 아무런 변화가 없어서 느껴지는 _________ 인 지연 도 있다.

• 정답 : 심리적 (Tmi.저해상도에서 고해상도로 바뀌게 하는 것도 심리적인 지연을 줄여주는데 효과가 좋다고 한다.) (p. 100)

📝 문제

4.4 　 병렬 커넥션　 hylee

1. 병렬 커넥션 방식을 이용하여 3개의 이미지가 있는 웹페이지를 브라우저가 보여줄 때 4개의 트랜잭션이 각각 별도의 커넥션에서 동시에 처리되어진다. (O/X)

• 정답 : X
  • Html 페이지를 내려받는 1개의 트랜잭션 이후 3개의 트랜잭션이 동시에 처리된다. (동시가 좀 애매하긴 하다. 보통은 스프트웨어의 성능 때문에 각 커넥션 요청 간에 약간의 지연이 있을 수 있다고 한다.) (p.102)

1. 병렬 커넥션은 단일 커넥션보다 항상 더 빠르지 않다. (O/X)

• 정답 : O
  • 일반적으로 병렬 커넥션이 더 빠르긴 하지만 다음과 같은 예에서는 더 오래 걸릴 수 있다. ex) 클라이언트의 네트워크 대역폭이 좁을 때, 대부분의 시간을 데이터를 전송하는데에 쓴다거나, 여러개의 커넥션을 생성하면서 생기는 부하 때문에 순차적으로 하는 것보다 오래 걸릴 수 있다. 📝 문제

4.5 　 지속 커넥션　 yeha

1. 지속 커넥션에 대한 설명으로 거리가 먼 것을 모두 고르세요. (3)
   (1) 요청에 대한 처리가 완료된 후 TCP 커넥션을 유지하며 앞으로 있을 HTTP 요청에 재사용한다. (O)
   (2) 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지한다. (O)
   (3) TCP의 느린 시작으로 인한 지연을 피함으로써 대역폭은 소요되지만 시간을 절약할 수 있다. (X)
   => 해당 서버에 이미 맺어져 있는 지속 커넥션을 재사용함으로써 커넥션을 맺기 위한 사전작업과 지연을 줄여 시간을 절약할 수 있다. 또한 커넥션이 이미 맺어져 있기 때문에 TCP의 느린 시작으로 인한 지연을 피함으로써 더 빠르게 데이터를 전송할 수 있다. 병렬 커넥션은 각 트랙잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
   (4) 수많은 커넥션이 계속 연결된 상태로 쌓이게 되면 불필요한 소모가 발생한다. (O)
   (5) 병렬 커넥션과 함께 사용하면 효과적이다. (O)

2. 초기 keep-alive 커넥션에 대한 설명으로 거리가 먼 것을 모두 고르세요. (3)
   (1) 초기 keep-alive 커넥션은 상호 운용과 관련된 설계에 문제가 있었다. (O)
   (2) 아직까지 많은 클라이언트와 서버에서 사용되고 있다. (O)
   (3) (1)에서 언급한 설계상의 문제는 수정되지 않았다. (X)
   => 초기 keep-alive 커넥션의 설계상의 문제는 HTTP/1.1에서 수정되었다.

3. keep-alive에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) HTTP/1.0에서 기본으로 사용되지는 않는다. (O)
   (2) HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해 요청에 Connection:Keep-Alive 헤더를 반드시 포함시켜야 한다. (O)
   (3) (1)의 요청을 받은 서버는 응답 메세지에 반드시 같은 헤더를 포함시켜서 응답해야 한다. (X) => (1)의 응답을 받은 서버는 다음 요청도 이 커넥션을 통해 받고자 할 때, 응답 메세지에 같은 헤더를 포함시켜서 응답한다.
   (4) 클라이언트나 서버는 keep-alive 요청을 받을 시 keep-alive 커넥션을 유지한다. (X)
   => keep-alive 요청을 받았다고 해서 무조건 따를 필요는 없다. 또한 현재의 keep-alive 커넥션을 끊거나 커넥션에서 처리되는 트랙잭션의 수를 제한할수도 있다.
   (5) keep-alive 응답 헤더를 통해 보내는 옵션 (timeout, max 파라미터 ..)는 지정한 대로 동작된다. (X)
   => 두 파라미터 모두 그대로 동작한다는 보장은 없다. (P.107)
   (6) 커넥션이 끊어지기 전 엔터티 본문의 길이를 알아야 커넥션을 유지할 수 있다. (O)
   (7) 프락시와 게이트웨이는 Connection 헤더의 규칙을 철저하게 지켜야 한다. (O)

4. HTTP/1.1의 지속 커넥션에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) HTTP/1.1에서는 keep-alive 커넥션과 설계가 더 개선된 지속 커넥션을 지원한다. (X)
   => HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는다.
   (2) 별도 설정을 하지 않는 한 모든 커넥션을 지속 커넥션으로 취급한다. (O)
   (3) 커넥션을 끊으려면 헤더를 포함시키지 않은 요청/응답을 보내면 된다. (X)
   => Connection: close 헤더를 명시해야 한다. Connection: close헤더를 보냈으면 그 커넥션으로 추가적인 요청을 보낼 수 없다. 응답에 Connection: close헤더가 없으면 응답 후에도 HTTP/1.1 커넥션을 유지하자는 것으로 추정한다.
   (4) HTTP/1.1 애플리케이션은 중간에 끊어지는 커넥션을 복구할 수 있어야 한다. (O) (p.113)

5. Proxy-Connection 헤더에 대한 설명으로 맞으면 O, 틀리면 X하세요.
   (1) 영리한 프락시는 의미 없는 비표준 Proxy-Connection 확장 헤더를 Connection 헤더로 바꾸어 전달한다. (O)
   (2) 멍청한 프락시는 Proxy-Connection 헤더 역시 무조건 전달하지만 웹 서버가 무시하기 때문에 문제가 되지 않는다. (O)

📝 문제

4.6 　 파이프라인 커넥션　 kukim

1. http 클라이언트는 지속커넥션 여부와 상관없이 파이프라인을 연결할 수 있다.(O/X)

• 정답 : X
  • 지속커넥션인지 확인하기 전까지는 파이프라인을 이어선 안된다.

2. http 클라이언트는 지속 커넥션 응답에 대해 요청 순서와 상관없이 Content-Length을 통해 정렬하여 해석할 수 있다. (O/X)

• 정답 : X
  • http 응답은 요청 순서와 같게 와야한다. http 메세지는 순번이 매겨져 있지 않아서 응답이 순서없이 오면 순서에 맞게 정렬 시킬 방법이 없다.

3. http 지속 커넥션의 요청에 대한 서버의 응답 메세지가 어떠한 오류로 끊어지더라도 서버에서 이를 기억하여 다시 보내준다. (O/X)

• 정답 : X
  • http 클라이언트는 커넥션이 언제 끊어지더라도 완료되지 않은 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어야 한다.

4. 모든 메서드는 파이프라인 커넥션을 사용할 수 있다. (O/X)

• 정답 : X
  • 멱등한 메서드만 사용할 수 있다. 비멱등(nonidempotent)한 메서드를 사용하여 에러가 발생하면 파이프라인을 통한 요청 중 어떤 것들이 서버에서 처리가 되었는지 알 수 없기 때문에 요청을 재차 보내면 문제가 생길 수 있다.

5. (+a) 현재 HTTP/1.1 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어 사용되고 있다. (O/X)

• 정답 : O
  • HTTP 파이프라이닝은 모던 브라우저에서 기본적으로 활성화되어있지 않다.
  • 왜냐하면 정확히 구현해내기 어렵기 때문이다. 전송 중인 리소스의 크기, 효과적인 RTT(Round-trip delay, 왕복지연시간), 대역폭 크기의 설정, HOL(Head of Line Blocking, 헤드라인차단, 첫 번째 패킷이 응답이 올 때 까지, 이전 요청이 완료 될 때 까지 기다리는)으로 문제가 된다.
  • 파이프라이닝은 HTTP/2로 오면서 멀티플렉싱으로 대체 되어 사용된다.
  • 한 줄 요약 : 파이프라인 커넥션은 잘 사용하지 않는다. (왜 공부한거니)
• https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x#HTTP_파이프라이닝

📝 문제

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

1. HTTP 커넥션은 반드시 메세지를 다 보낸 후 종료된다. (O/X)

• 정답 : X
  • 보통 커넥션은 메세지를 다 보낸 다음 끊지만 종종, 자주 에러가 있는 상황에서 헤더의 중간에서 끊거나 엉뚱한 곳에서 잘리기도 한다.

2. Content-Length 헤더의 역할은 무엇인가? (주관식)

• 실제 받아야하는 엔터티와 실제로 전달받은 엔터티의 차이를 확인하는 헤더이다. 클라이언트나 프락시 서버가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달된 엔터티의 길이와 Content-Length의 값이 일치하지 않거나 Content-Length 값 자체가 존재하지 않으면 수신다는 데이터의 정확한 길이를 서버에게 물어봐야 한다.

3. HTTP/1.1 명세에서 언제, 어떻게 커넥션을 끊는가에 대한 명확한 기준이 정해져있다. (O/X)

• 정답 : X
  • ‘우아하게 커넥션을 끊어야 한다’ 라고만 적혀있다. (issue a graceful close on the transport connection)

4. 우아하게

• ‘우아하게 커넥션을 끊는 방법 중’ 클라이언트가 예기치 않은 상황에서 커넥션을 끊어야 할 때 절반 끊기 중 (입력/출력 채널)을 끊는다.
  • (출력채널)을 끊어야 한다. 입력 채널을 끊는다면 이 전에 요청한 커넥션에 대한 결과를 서버에서 응답받을 수 없기 때문이다.
• 절반 끊기 (입력/출력 채널)을 끊은 후 우아하게 기다린다. (O/▲/X)
  • 우아하게 기다리면서 데이터나 스트림의 끝을 식별하기 위해 입력 채널에 대한 상태 검사를 주기적으로 해야한다.

📝 문제

맨위로　📄 퀴즈해설 바로가기