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

목록

▸ TCP 커넥션▸ TCP 성능에 대한 고려▸ HTTP 커넥션 관리▸ 병렬 커넥션▸ 지속 커넥션▸ 파이프라인 커넥션▸ 커넥션 끊기에 대한 미스터리

TCP 커넥션

TCP 커넥션

웹브라우저가 TCP 커넥션을 통해 웹 서버에 요청을 보낸다1. 브라우저가 주소창에 `www.joes-hardware.com` 라는 호스트 명을 추출한다 .2. 브라우저가 이 호스트 명에 대한 IP 주소를 찾는다3. 브라우저가 포트 번호 (80) 를 얻는다 .4. 브라우저가 202.43.78.3 의 80 포트로 TCP 커넥션을 생성한다 .5. 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다 .6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다 . 7. 브라우저가 커넥션을 끊는다 .

TCP 커넥션

▸ TCP 는 HTTP 에게 신뢰성을 제공한다▸ TCP 는 스트림을 세그먼트로 나누고 IP패킷으로 랩핑해서 보낸다

TCP 커넥션

▸ TCP 커넥션 구별▸ 발신지 IP 주소▸ 발신지 PORT

▸ 수신지 IP 주소▸ 수신지 PORT

TCP 커넥션

클라이언트와서버가 TCP 소켓을 인터페이스로 통신A. 서버가 새로운 소켓을 만든다 socket()B. 서버가 80 포트로 소켓을 묶는다 bind()C. 서버가 소켓 커넥션을 허가한다 listen()D. 서버가 커넥션을 기다린다 accept()E. 클라이언트가 접속할 IP 와 포트를 얻는다F. 클라이언트가 새로운 소켓을 생성한다

socket()G. 클라이언트가 서버의 IP 로 연결한다

connect()H. 서버가 애플리케이션 커넥션을 통지한다I. 서버가 요청을 읽기 시작한다

J . 클라이언트가 성공적으로 연결된다K. 클라이언트가 HTTP 요청을 보낸다

write()L. 클라이언트가 HTTP 응답을 기다린다

read()M. 서버가 HTTP 요청을 처리한다N. 서버가 HTTP 응답을 보낸다 write()O. 클라이언트가 응답을 처리한다P. 클라이언트가 커넥션을 닫는다 close()Q. 서버가 커넥션을 닫는다 close()

TCP 의 성능에 대한 고려

TCP 의 성능에 대한 고려

▸ HTTP 느리다 !

1. DNS 찾기2. 연결3. 클라이언트가 요청4. 서버가 처리5. 서버가 응답

TCP 의 성능에 대한 고려

▸ HTTP 느리다 !

1. DNS 찾기2. 연결3. 클라이언트가 요청4. 서버가 처리5. 서버가 응답

TCP 의 성능에 대한 고려

확인응답 지연▸ 요청과 응답으로 이루어진 HTTP 의 동작 특성상 TCP 세그먼트에 편승

(Piggyback) 할 기회가 많지 않다

TCP 의 성능에 대한 고려

TCP 느린 시작▸ TCP 커넥션은 시간이 지나면 자체 튜닝되면서 빨리진다▸ 이걸로 네트웍의 갑작스러 부하 , 혼잡 제어▸ 그래서 TCP 커넥션을 재사용 하면 좋다

TCP 의 성능에 대한 고려

네이글 알고리즘과 TCP_NODELAY▸ TCP 세그먼트가 최대 크기가 되지 않으면 전송을 하지않고 기다린다▸ 네이글 + 확인응답지연 + 파이프라인 커넥션 = 느리다▸ 그래서 TCP_NODELAY 옵션을 사용

TCP 의 성능에 대한 고려

TIME_WAIT 의 누적과 포트 고갈▸ TCP 커넥션의 종단에서 TCP 커넥션을 끊으면 , 종단에서는 커넥션의 IP 와 포트 번호를 메모리에 기록해 놓는다▸ 이 정보는 일정시간동안 같은 커넥션이 대략 2 분 (2MSL: 세그먼트 생명주기

*2) 동안 생성되는걸 막아준다▸ 웹서버를 기준으로 클라이언트가 80 포트에 2MSL 동안 대략 60,000 개의 포트를 고갈 시키려면 초당 500 개의 커넥션을 맺어야 한다

HTTP 커넥션 관리

HTTP 커넥션 관리

HTTP CONNECTION 헤더▸ HTTP 는 클라이언트와 서버 사이에 프락시 , 캐시 서버가 놓이는것을 감안하고 만들어 졌다▸ Connection 헤더에 홉별 (hop-by-hop) 헤더를 기술하고 기본적으로 홉별 헤더인것도 있다

▸ Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade

▸ Connection 헤더는 , Meter 헤더를 다른 커넥션으로전달하면 안 되고 ‘ bill-my-credit-card’ 옵션을 적용할 것이며 이 트랜잭션이 끝나면 커넥션이 끈길 것이라고 말한다

HTTP 커넥션 관리

순차적인 트랜잭션 처리에 의한 지연▸ HTML 하나를 받고 이미지 3 개를 더 받는 그림 , 오래 걸린다

병렬 커넥션

병렬 커넥션

▸ 클라이언트가 여러개의 커넥션을 맺고 동시에 리소스를 처리한다▸ 대역폭이 낮고 처리해야할 데이터 전송량이 많으면 장점이 없다▸ 많은 커넥션을 허용할 수록 서버는 힘들다▸ 최신 브라우저는 6 개에서 8 개의 커넥션을 만든다

지속 커넥션

지속 커넥션

▸ HTTP/1.1 을 지원하면 사용할 수 있다▸ HTTP 트랜잭션이 끊나도 TCP 연결은 끊지 않고 재사용 한다▸ 서버쪽이나 클라이언트쪽의 이유로

TCP 연결을 재사용 못 할 수 있다▸ 재사용한 TCP 연결은 TCP 느린 시작을 회피하고 핸드세이크도 하지 않아 더 빠르다▸ 병렬 커넥션과 같이 사용하면 좋다▸ HTTP/1.0+ 는 Keep-Alive

▸ HTTP/1.1 는 Persistent Connection

지속 커넥션

KEEP-ALIVE 커넥션 제한과 규칙▸ 클라이언트는 Connection: Keep-Alive 요청 헤더를 보낸다▸ 클라이언트는 Keep-Alive 연결을 유지하려면 계속 Keep-Alive 요청 헤더를 보낸다▸ 클라이언트는 응답 헤더에 Connection: Keep-Alive 가 없으면 서버가 응답 후 커넥션을 끊었다고 간주한다▸ Content-Length 헤더는 정확히 보내야 한다▸ 프락시와 게이트웨이는 메시지를 전달하거나 캐시에 넣기 전에 Connection 헤더에 명시된 모든 헤더 필드와 Connection 헤더를 제거해야 한다▸ 멍청 프락시가 중간에 있으면 곤란하다▸ 기술적으로 HTTP/1.0 을 따르는 기기로부터 받은 모든 Connection 헤더 필드는 무시해야한다

지속 커넥션

KEEP-ALIVE 와 멍청 프락시▸ 클라이언트가 Connection: Keep-Alive▸ 서버는 Keep-Alive 요청을 받았기때문에 , 처리가 완료된 후에도 커넥션을 끊지 않는다▸ 프락시는 해당 커넥션을 통해 들어오는 새 요청을 모두 무시하면서 커넥션이 끊어지기를 기다린다▸ 멍청 프락시가 클라이언트에게 Connection: Keep-Alive 를 응답▸ 프락시는 서버와의 커넥션이 끊어지는 것을 기다리고 있기 때문에 , 해당 Keep-Alive 커넥션을 통해서 오는 클라이언트의 두 번째 요청이 Hang▸ 멍청 프락시는 다음 헤더는 전달하면 안된다

▸ Conneciton, Keep-Alive▸ Proxy-Authenticate, Proxy-Conneciton▸ Transfer-Encoding, Upgrade

지속 커넥션

PROXY-CONNECTION 살펴보기▸ 비표준▸ 클라이언트는 Connection 헤더 대신

Proxy-Connection 사용▸ 영리한 프락시는 서버쪽으로 Proxy-

Connection 을 제거하고 Connection: Keep-Alive 로 교체 , 멍청 프락시는 그대로 전달

▸ 멍청 프락시만 있으면 잘 작동▸ 프락시가 많으면 망함

지속 커넥션

지속 커넥션 제한과 규칙▸ HTTP/1.1 은 기본이 지속 커넥션▸ 클라이언트는 해당 커넥션으로 추가 요청을 보내지 않으려면 Connection:

close 헤더를 보내고 추가 요청을 보내지말아야 한다▸ Content-Length 꼭 있어야하거나 청크 전송 인코딩으로 인코드 되어 있어야 한다▸ HTTP/1.1 프락시는 클라이언트 , 서버 각각 별도로 지속 커넥션을 가진다▸ 서버 , 클라이언트 모두 언제 지속 커넥션이 끊겨도 상관없이 작동해야 한다▸ 클라이언트는 넉넉잡아 2 개의 커넥션만 유지한다

▸ N 명의 사용자가 접근하는 프락시는 2N 개의 커넥션을 유지한다

파이프라인 커넥션

파이프라인 커넥션

▸ HTTP 응답은 요청 순서와 같아야한다▸ 파이프 라인 중간에 끊겨도 다시 커넥션을맺고 다시 요청을 보낼 수 있어야 한다▸ POST 메소드 같은 비멱등 요청은 다시 보내지 않는다

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

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

▸ 언제 커넥션을 끊는지 기준이 없다▸ 에러가 없어도 아무때나 끊을 수 있다▸ POST 는 비멱등이라 중간에 전송이끊기면 다시 보내지 않고 사용자에게 대화상자로 물어본다▸ TCP 는 양방향 입출력을 갖는다 . 그래서 절반만 끊을 수 있다 .

▸ shutdown() vs close()▸ 일반적으로 우아하게 커넥션을 끊으려면 출력 채널을 끊고 입력 채널을 주기적으로 검사한 후 특정 시간 이후 끊기지 않으면 리소스 보호를 위해 강제로 끊는다