[HTTP/1.1] Persistent Connection / Simultaneous Connections / Pipeline / Domain Sharding

# 낙서장 #

 

이미 HTTP/2, HTTP/3이 나오는 마당에 뒷북 아닌가 싶기도 한데 알고 있던 내용을 적어본다.

 

HTTP/1.1에서의 속도 개선 방법 '도메인 샤딩' 개념을 표준과 비교해서 살펴보자.

 

 

o 표준/스펙

Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616)

    https://tools.ietf.org/html/rfc2616

'8장'에서 HTTP 연결에 대해 설명하고 있다. 한번 쭉 읽어보자. 

 

8. Connection

8.1 Persistent Connections <-- 흔히 말하는 keep-alive 연결로 이해하면 되고

8.1.1 Purpose

8.1.2 Overall Operation

8.1.2.1 Negotiation

8.1.2.2 Pipelining

  다수의 요청을 보낼 persistent connections가 곧 파이프라인이 되는데,

  주의해야 할 부분은 'non-idempotent methods' 가 파이프라인으로 전달되는 요청에 없어야 한다는 것.

  POST 등 데이터를 보내 서버의 데이터가 변할 수 있는 부류의 요청 건.

  idempotent methods용어와 의미를 기억해두자.

8.1.3 Proxy Servers

8.1.4 Practical Considerations

  어라 개정 전/후 표현 내용이 at most, not ~ more than으로

  서버당 많아야 2개 정도의 persistent connection을 maintain해야 한다고 정의되어 있다.

RFC2068 #8.1.4

RFC2616 #8.1.4

 

Client 브라우저별 hostname당 연결 수가 아래와 같다고 한다. 제각각이다. -_-

http://www.browserscope.org/?category=network&v=1

https://en.wikipedia.org/wiki/HTTP_persistent_connection

http://sgdev-blog.blogspot.com/2014/01/maximum-concurrent-connection-to-same.html

 

바로 여기서 HTTP/1.1 기반 성능 튜닝법으로 리소스별

hostname분리 = domain sharding 도메인 샤딩 기술이 나오게 된거라고 보면 된다.

 

24개 이미지 로딩이 필요한 웹 페이지의 경우 (연결시 RTT, DNS조회, 쓰레드 컨텍스트 스위칭 등의 지연은 없다고 가정)

 > http://hostname/image/1.png ~ 24.png일 경우 (단일 도메인) & 6개의 연결이 사용된다고 가정할 때,

   1) 6개 요청 > 응답 오기까지 나머지 요청건 대기

      (Pipelining참고, 뒤에 대기하고 있는 15개의 요청 = queued or stalled 상태의 request)

   2) 응답 수신 후 6개... 결국 6개 리소스 set의 4번 반복으로 로딩 완료.

   --> 6개 응답 수신까지 10ms가 소요된다고 가정, 총 40ms 소요

 > http://grp1.hostname.grp1/image/1.png~6.png, http://grp2.hostname.grp1/image/7.png~12.png

    http://grp3.hostname.grp1/image/13.png~18.png, http://grp4.hostname.grp1/image/19.png~24png

    이와 같이 4개 hostname으로 구성하고 각각 6개의 이미지를 구분해놨다면,

    브라우저는 서로 hostname각각 6개의 연결을 맺고 응답 대기 없이 전부 동시 요청.

 

   ex) 쿠팡과 11번가 비교

 

이외에도 Android의 okhttp, ios의 alamofire등 REST API client 라이브러리들도 이와 같은 동작은 마찬가지이다.

(ios의 경우 host당 4개 연결로 customize가 불가한 듯 싶고, okhttp의 경우 customize가능한 것으로 보임)

 

요청 유형이 idempotent methods(GET/PUT/DELETE/...)여야 하고, 서버의 자원은 유한하니 graceful shutdown이 잘 이뤄지지 않으면 소켓 상태 전이로 자원의 즉시 반환이 되지 않아 즉각적인 재활용 불가, 많은 hostname의 dns조회, RTT 등 단점 역시 존재하니, 여러 조건/환경(들)을 주의 해야 한다. Pros vs Cons of Domain Sharding

 

서비스 구현을 HTTP2등으로 고민하고 있다면 HTTP/1.1은 그냥 쓰던대로 두자. 귀찮다.

 

 

HTTP2의 경우는 1개의 연결로 여러개의 요청/응답을 주고 받도록 (muxing/demuxing),

HTTP3의 경우는 TCP의 RTT제거를 위해 UDP를 사용하는 등,

HTTP/1.1의 비효율/성능개선 등의 개정 버전이 이미 사용되고 있으니.

 

 

[기타 참고]

Referer 헤더 철자 오류

 - 스펠링 오류인 채로 표준 정의 & 널리 사용되어 그냥 어쩔 수 없이 쓰게됨.

왜 이렇게 되었는지에 대해서 궁금하면 '이곳','저곳,그곳' 참고.

 

 

[참고]

https://stackoverflow.com/questions/45016234/what-is-idempotency-in-http-methods

https://en.wikipedia.org/wiki/HTTP_persistent_connection

 

https://tools.ietf.org/html/rfc2068

https://tools.ietf.org/html/rfc2616

https://tools.ietf.org/html/rfc7230

https://tools.ietf.org/html/rfc7231

 

http://www.ibiblio.org/mdma-release/http-prob.html