5. 커넥션 관리(2편)

2022 우아한스터디 "HTTP 완벽가이드"를 진행하면서

'HTTP 완벽 가이드' 책을 읽고, 글쓴이의 생각을 정리하는 글 입니다.

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980 

HTTP 완벽 가이드

 

 

1. 병렬커넥션

병렬커넥션. 이름에서 볼 수 있듯

 

Server와 Client간 병렬로 Connection을 생성해서 한번에 여러 요청을 보내는 방식 입니다.

(이때 대역폭을 고려해야하며, 대역폭이 가능하다면 최대 N배의 성능이 가능함)

 

하지만 위에서 볼 수 있듯, 한명의 유저가 N개의 Connection을 생성하기 때문에

 

Server입장에서는 유저수 * N개의 Connection을 관리하게 됩니다. 때문에 유저수가 증가할 경우 Server의 부담이 크게 증가하게 됩니다.

 

2. keep-alive/지속커넥션

Connection은 핸드쉐이크를 한번 하고, 그 이후에 추가적으로 Clinet의 요청 -> Server의 응답이 이어집니다.

 

이때 이 핸드쉐이크 지연을 방지하는 방법 중 하나입니다.

 

기조의 경우 핸드쉐이크 -> Client 요청 -> Server의 응답 이후 Connection이 끊어졌다면,

 

지속커텍션의 경우 핸드쉐이크 -> Client 요청 -> Server의 응답 -> 대기... -> Client 요청...

 

으로 통신이 진행 됩니다.

 

이를 위해서 Keep-Alive 라는 http header를 추가해서 전송합니다.

(ex. Keep-Alive : max = 5, timeout = 120)

 

서버에서는 이 요청을 분석해서 Client와의 연결을 유지합니다.

(이 과정에서, Proxy가 끼게되면 "멍청한 proxy" 라는 문제가 발생합니다. 요건 나중에...)

 

※근데, 반전은 HTTP 1.0까지만 keep-alive 커넥션을 사용하고, 1.1부터는 기본적으로 지속커넥션 을 사용합니다.

 

때문에 Server에서 유동적으로 Conenction을 끊거나, 아니면 Client에서 Connection:Close를 Header에 포함해서 보내게 됩니다.

 

3. 파이프라인 커넥션

파이프라인은 CPU에서 사용하는 용어인데, HTTP에서는 의미가 좀 다릅니다.

 

개념은 파이프라인보다는 병렬 처리에 가까운 편입니다.

 

예를들어, 지속Connection을 유지한 상태에서 요청 1,2,3,4,5가 있다고 할 때

 

요청 1을 보내고, 요청 1의 응답이 오기 전에 요청 2를 보내는 식으로 여러개의 요청이 중첩된 상태로 Server에 Requests가 전달되게 됩니다.

 

CPU의 경우 파이프라인이라 하면 한개의 작업을 여러 단계로 분할하여 해당 작업을 순서대로 처리하면서 여러 작업이 동시에 처리되는 방식입니다. HTTP의 파이프라인과는 좀 다르죠.

 

파이프라인 프로그래밍의 경우 중간에 서버에서 임의로 Connection을 끊을수 있기 때문에, 반듯이 성공해야하는 작업의 경우 이 커넥션을 사용하지 말라고 되어있습니다.

 

--> 위 문구에서 알 수 있듯, 병렬Connection은 다수의 Connection을 만드는 반면 파이프라인 커넥션은 하나의 Connection에다가 다수의 Requests를 보내는 방식이라고 할 수 있습니다.