ݺߣ

ݺߣShare a Scribd company logo

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

•Download as PPTX, PDF•
•
박 민규
박 민규

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

1 of 30
Downloaded 22 times
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()
HTTP 완벽가이드 4장 커넥션관리
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() ▸일반적으로 우아하게 커넥션을 끊으려면 출력 채널을 끊고 입 력 채널을 주기적으로 검사한 후 특정 시간 이후 끊기지 않으 면 리소스 보호를 위해 강제로 끊는다

More Related Content

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

  • 1. HTTP 완벽 가 4장 커넥션 관리
  • 2. 목록 ▸TCP 커넥션 ▸TCP 성능에 대한 고려 ▸HTTP 커넥션 관리 ▸병렬 커넥션 ▸지속 커넥션 ▸파이프라인 커넥션 ▸커넥션 끊기에 대한 미스터리
  • 4. TCP 커넥션 웹브라우저가 TCP 커넥션을 통해 웹 서버에 요청을 보낸다 1. 브라우저가 주소창에 `www.joes-hardware.com`라는 호스트 명을 추 출한다. 2. 브라우저가 이 호스트 명에 대한 IP 주소를 찾는다 3. 브라우저가 포트 번호(80)를 얻는다. 4. 브라우저가 202.43.78.3의 80포트로 TCP 커넥션을 생성한다. 5. 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다. 6. 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다. 7. 브라우저가 커넥션을 끊는다.
  • 5. TCP 커넥션 ▸ TCP는 HTTP에게 신뢰성을 제공한 다 ▸ TCP는 스트림을 세그먼트로 나누고 IP패킷으로 랩핑해서 보낸다
  • 6. TCP 커넥션 ▸ TCP 커넥션 구별 ▸ 발신지 IP 주소 ▸ 발신지 PORT ▸ 수신지 IP 주소 ▸ 수신지 PORT
  • 7. 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()
  • 10. TCP의 성능에 대한 고려 ▸ HTTP 느리다! 1. DNS찾기 2. 연결 3. 클라이언트가 요청 4. 서버가 처리 5. 서버가 응답
  • 11. TCP의 성능에 대한 고려 ▸ HTTP 느리다! 1. DNS찾기 2. 연결 3. 클라이언트가 요청 4. 서버가 처리 5. 서버가 응답
  • 12. TCP의 성능에 대한 고려 확인응답 지연 ▸ 요청과 응답으로 이루어진 HTTP의 동작 특성상 TCP 세그먼트에 편승 (Piggyback)할 기회가 많지 않다
  • 13. TCP의 성능에 대한 고려 TCP 느린 시작 ▸ TCP 커넥션은 시간이 지나면 자체 튜닝되면서 빨리진다 ▸ 이걸로 네트웍의 갑작스러 부하, 혼 잡 제어 ▸ 그래서 TCP 커넥션을 재사용 하면 좋다
  • 14. TCP의 성능에 대한 고려 네이글 알고리즘과 TCP_NODELAY ▸ TCP 세그먼트가 최대 크기가 되지 않으면 전송을 하지않고 기다린다 ▸ 네이글 + 확인응답지연 +파이프라인 커넥션 = 느리다 ▸ 그래서 TCP_NODELAY 옵션을 사용
  • 15. TCP의 성능에 대한 고려 TIME_WAIT의 누적과 포 트 고갈 ▸ TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP와 포트 번호를 메모리에 기록해 놓는다 ▸ 이 정보는 일정시간동안 같은 커넥션이 대략 2분(2MSL: 세그먼트 생명주 기*2)동안 생성되는걸 막아준다 ▸ 웹서버를 기준으로 클라이언트가 80포트에 2MSL 동안 대략 60,000개의 포트를 고갈 시키려면 초당 500개의 커넥션을 맺어야 한다
  • 17. HTTP 커넥션 관리 HTTP CONNECTION 헤 더 ▸ HTTP는 클라이언트와 서버 사이에 프락 시, 캐시 서버가 놓이는것을 감안하고 만 들어 졌다 ▸ Connection 헤더에 홉별(hop-by-hop) 헤 더를 기술하고 기본적으로 홉별 헤더인것 도 있다 ▸ Proxy-Authenticate, Proxy- Connection, Transfer-Encoding, Upgrade ▸ Connection 헤더는, Meter헤더를 다른 커 넥션으로전달하면 안 되고 ‘bill-my-credit- card’ 옵션을 적용할 것이며 이 트랜잭션 이 끝나면 커넥션이 끈길 것이라고 말한 다
  • 18. HTTP 커넥션 관리 순차적인 트랜잭션 처리에 의 한 지연 ▸ HTML 하나를 받고 이미지 3개를 더 받는 그림, 오래 걸린다
  • 20. 병렬 커넥션 ▸ 클라이언트가 여러개의 커넥션을 맺 고 동시에 리소스를 처리한다 ▸ 대역폭이 낮고 처리해야할 데이터 전 송량이 많으면 장점이 없다 ▸ 많은 커넥션을 허용할 수록 서버는 힘들다 ▸ 최신 브라우저는 6개에서 8개의 커 넥션을 만든다
  • 22. 지속 커넥션 ▸ HTTP/1.1을 지원하면 사용할 수 있 다 ▸ HTTP 트랜잭션이 끊나도 TCP 연결 은 끊지 않고 재사용 한다 ▸ 서버쪽이나 클라이언트쪽의 이유로 TCP연결을 재사용 못 할 수 있다 ▸ 재사용한 TCP 연결은 TCP느린 시작 을 회피하고 핸드세이크도 하지 않아 더 빠르다 ▸ 병렬 커넥션과 같이 사용하면 좋다 ▸ HTTP/1.0+ 는 Keep-Alive ▸ HTTP/1.1 는 Persistent Connection
  • 23. 지속 커넥션 KEEP-ALIVE 커넥션 제한과 규칙 ▸클라이언트는 Connection: Keep-Alive 요청 헤더를 보낸다 ▸클라이언트는 Keep-Alive 연결을 유지하려면 계속 Keep-Alive 요청 헤더를 보낸다 ▸클라이언트는 응답 헤더에 Connection: Keep-Alive가 없으면 서버가 응답 후 커넥 션을 끊었다고 간주한다 ▸Content-Length헤더는 정확히 보내야 한다 ▸프락시와 게이트웨이는 메시지를 전달하거나 캐시에 넣기 전에 Connection 헤더에 명시된 모든 헤더 필드와 Connection 헤더를 제거해야 한다 ▸멍청 프락시가 중간에 있으면 곤란하다 ▸기술적으로 HTTP/1.0을 따르는 기기로부터 받은 모든 Connection 헤더 필드는 무 시해야한다
  • 24. 지속 커넥션 KEEP-ALIVE와 멍청 프락 시 ▸ 클라이언트가 Connection: Keep-Alive ▸ 서버는 Keep-Alive 요청을 받았기때문에, 처리가 완료된 후 에도 커넥션을 끊지 않는다 ▸ 프락시는 해당 커넥션을 통해 들어오는 새 요청을 모두 무 시하면서 커넥션이 끊어지기를 기다린다 ▸ 멍청 프락시가 클라이언트에게 Connection: Keep-Alive를 응답 ▸ 프락시는 서버와의 커넥션이 끊어지는 것을 기다리고 있기 때문에, 해당 Keep-Alive 커넥션을 통해서 오는 클라이언트 의 두 번째 요청이 Hang ▸ 멍청 프락시는 다음 헤더는 전달하면 안된다 ▸ Conneciton, Keep-Alive ▸ Proxy-Authenticate, Proxy-Conneciton ▸ Transfer-Encoding, Upgrade
  • 25. 지속 커넥션 PROXY-CONNECTION 살펴보기 ▸ 비표준 ▸ 클라이언트는 Connection 헤더 대신 Proxy-Connection사용 ▸ 영리한 프락시는 서버쪽으로 Proxy- Connection을 제거하고 Connection: Keep-Alive로 교체, 멍청 프락시는 그대로 전달 ▸ 멍청 프락시만 있으면 잘 작동 ▸ 프락시가 많으면 망함
  • 26. 지속 커넥션 지속 커넥션 제한과 규칙 ▸HTTP/1.1 은 기본이 지속 커넥션 ▸클라이언트는 해당 커넥션으로 추가 요청을 보내지 않으려면 Connection: close 헤더를 보내고 추가 요청을 보내지말아야 한다 ▸Content-Length 꼭 있어야하거나 청크 전송 인코딩으로 인코드 되어 있어 야 한다 ▸HTTP/1.1 프락시는 클라이언트, 서버 각각 별도로 지속 커넥션을 가진다 ▸서버, 클라이언트 모두 언제 지속 커넥션이 끊겨도 상관없이 작동해야 한 다 ▸클라이언트는 넉넉잡아 2개의 커넥션만 유지한다 ▸N명의 사용자가 접근하는 프락시는 2N개의 커넥션을 유지한다
  • 28. 파이프라인 커넥션 ▸ HTTP 응답은 요청 순서와 같아야한 다 ▸ 파이프 라인 중간에 끊겨도 다시 커 넥션을맺고 다시 요청을 보낼 수 있 어야 한다 ▸ POST 메소드 같은 비멱등 요청은 다 시 보내지 않는다
  • 30. 커넥션 끊기에 대한 미스터리 ▸언제 커넥션을 끊는지 기준이 없다 ▸에러가 없어도 아무때나 끊을 수 있다 ▸POST 는 비멱등이라 중간에 전송이끊기면 다시 보내지 않고 사용자에게 대화상자로 물어본다 ▸TCP는 양방향 입출력을 갖는다. 그래서 절반만 끊을 수 있다. ▸shutdown() vs close() ▸일반적으로 우아하게 커넥션을 끊으려면 출력 채널을 끊고 입 력 채널을 주기적으로 검사한 후 특정 시간 이후 끊기지 않으 면 리소스 보호를 위해 강제로 끊는다