지속적 연결: Difference between revisions

From IT Wiki
(새 문서: * '''상위 문서: HTTP''' '''Persistent Connection'''지속적 연결은 '''HTTP/1.1'''에서 도입된 기술로, 한 번 설정된 TCP 연결을 여러 요청에 걸쳐 유지하는 방식이다. 이를 통해 각 요청마다 새로운 연결을 설정하고 종료하는 과정을 반복하는 대신, '''하나의 연결을 여러 리소스 요청에 사용'''하여 효율성을 높일 수 있다. == HTTP/1.0와의 가장 큰 차이 == * '''HTTP/1.0''':...)
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:


* '''상위 문서: [[HTTP]]'''
* '''상위 문서: [[HTTP]]'''
'''Persistent Connection'''지속적 연결은 [[HTTP 1.1|'''HTTP/1.1''']]에서 도입된 기술로, 한 번 설정된 TCP 연결을 여러 요청에 걸쳐 유지하는 방식이다. 이를 통해 각 요청마다 새로운 연결을 설정하고 종료하는 과정을 반복하는 대신, '''하나의 연결을 여러 리소스 요청에 사용'''하여 효율성을 높일 수 있다.
'''Persistent Connection'''
 
지속적 연결은 [[HTTP 1.1|'''HTTP/1.1''']]에서 도입된 기술로, 한 번 설정된 TCP 연결을 여러 요청에 걸쳐 유지하는 방식이다. 이를 통해 각 요청마다 새로운 연결을 설정하고 종료하는 과정을 반복하는 대신, '''하나의 연결을 여러 리소스 요청에 사용'''하여 효율성을 높일 수 있다.


== HTTP/1.0와의 가장 큰 차이 ==
== HTTP/1.0와의 가장 큰 차이 ==

Latest revision as of 01:52, 25 October 2024

Persistent Connection

지속적 연결은 HTTP/1.1에서 도입된 기술로, 한 번 설정된 TCP 연결을 여러 요청에 걸쳐 유지하는 방식이다. 이를 통해 각 요청마다 새로운 연결을 설정하고 종료하는 과정을 반복하는 대신, 하나의 연결을 여러 리소스 요청에 사용하여 효율성을 높일 수 있다.

HTTP/1.0와의 가장 큰 차이[edit | edit source]

  • HTTP/1.0: HTTP/1.0에서는 기본적으로 비지속적 연결(non-persistent connection)을 사용했다. 이는 각 리소스 요청마다 새로운 TCP 연결을 설정하고, 응답이 완료되면 연결을 끊는 방식이다. 이로 인해 리소스가 많은 웹 페이지를 로드할 때마다 여러 번의 연결 설정과 해제가 반복되어 성능 저하가 발생했다.
  • HTTP/1.1: HTTP/1.1에서는 지속적 연결이 기본값으로 설정되었다. 이를 통해 한 번의 연결로 여러 개의 리소스를 요청할 수 있게 되어 웹 페이지 로딩 속도가 크게 향상되었다. HTTP/1.1은 지속적인 연결을 통해 네트워크 트래픽을 줄이고, 클라이언트와 서버의 자원 관리를 최적화했다.

Keep-Alive 헤더[edit | edit source]

  • Keep-Alive는 지속적 연결을 사용하는 경우, 클라이언트와 서버 간에 연결을 유지할 시간과 최대 요청 수를 정의하는 HTTP 헤더이다.
    • 이 헤더를 통해 연결이 얼마나 유지될지를 결정하고, 필요한 경우 더 오랫동안 연결을 유지할 수 있다.

장단점[edit | edit source]

장점[edit | edit source]

  • TCP 연결 설정 및 종료 비용 절감: 비지속적 연결에서는 각 리소스 요청마다 TCP 연결 설정(3-way handshake)과 종료(4-way handshake)가 필요했으나, 지속적 연결은 한 번의 연결로 여러 요청을 처리할 수 있어 이러한 오버헤드를 줄인다.
  • 지연 시간(Latency) 감소: 각 리소스마다 새로운 연결을 설정하지 않기 때문에, 초기 설정 시간 없이 연속적으로 리소스를 요청할 수 있어 전체 지연 시간이 줄어든다.
  • 네트워크 혼잡 감소: 매번 새로운 연결을 설정할 필요가 없기 때문에, 불필요한 네트워크 트래픽이 줄어들고, 이는 네트워크 혼잡을 완화하는 데 기여한다.
  • TCP 슬로우 스타트 문제 완화: 새로운 연결마다 TCP 슬로우 스타트가 발생하지만, 지속적 연결은 한 번 설정된 연결을 유지하므로 슬로우 스타트로 인한 성능 저하가 줄어든다.
  • 서버 및 클라이언트 자원 효율성: 서버와 클라이언트 모두 연결을 여러 번 설정하지 않기 때문에, 처리해야 할 연결 수가 줄어들고 자원 사용이 효율적이다.

단점[edit | edit source]

  • 서버 자원 고갈 위험: 연결을 오랫동안 유지해야 하므로 서버가 많은 수의 클라이언트와 지속적인 연결을 유지하면 자원이 고갈될 수 있다. 특히, 대규모 트래픽을 처리해야 하는 서버에서는 연결 과부하가 발생할 가능성이 높다.
  • 타임아웃 설정 문제: 연결을 언제까지 유지할지 결정하는 타임아웃 설정이 어렵다. 타임아웃이 너무 짧으면 연결이 자주 끊기고, 너무 길면 서버 자원이 불필요하게 점유될 수 있다.
  • 커넥션 유지 비용: 연결을 유지하는 동안 서버와 클라이언트 모두 지속적으로 자원을 소모해야 하므로, 연결이 많아질수록 비용이 증가한다.
  • 네트워크 혼잡 위험: 연결이 장시간 유지되면 다른 사용자들이 사용할 수 있는 네트워크 리소스가 줄어들어, 특정 시점에서 네트워크 혼잡이 발생할 수 있다.
  • 보안 위험: 장기간 연결을 유지하면서 세션 하이재킹, 중간자 공격 등 보안 위협에 노출될 가능성이 높아진다. 따라서 추가적인 보안 조치가 필요하다.
  • 프록시 서버와의 호환성 문제: 일부 프록시 서버는 지속적 연결을 제대로 지원하지 않을 수 있으며, 프록시 서버가 클라이언트와 서버 간의 다수의 연결을 유지해야 하므로 자원 소모가 커질 수 있다.

파이프라이닝과 멀티플렉싱[edit | edit source]

파이프라이닝[edit | edit source]

HTTP/1.1 Pipelining

  • HTTP 파이프라이닝은 지속적 연결을 이용해 여러 HTTP 요청을 연속적으로 보내는 방식이다. 즉, 서버가 첫 번째 요청에 응답하기 전에 두 번째 요청을 보낼 수 있다. 이를 통해 지연 시간을 더욱 줄일 수 있으나, 실제로는 복잡성과 호환성 문제로 인해 널리 사용되지는 않았다.
  • 파이프라이닝을 완벽히 지원하는 서버와 클라이언트 간의 통신에서 효율적이지만, 일부 서버는 요청 순서에 따라 응답을 보내지 못할 경우 문제가 발생할 수 있다. HTTP/2 이후 파이프라이닝은 멀티플렉싱으로 대체되었다.

멀티플렉싱[edit | edit source]

HTTP/2 Multiplexing

  • HTTP/2는 지속적 연결의 개념을 발전시켜, 멀티플렉싱을 도입했다. 멀티플렉싱은 한 번의 TCP 연결을 통해 여러 요청과 응답을 병렬 처리할 수 있도록 하여, HTTP/1.1의 지속적 연결보다 더 나은 성능을 제공한다. HTTP/2는 연결을 유지하면서 요청들을 분리된 스트림으로 처리하므로, 리소스를 동시에 효율적으로 전송할 수 있다.
  • 지속적 연결은 HTTP/2의 근간이 되었으며, 이를 통해 더 많은 최적화가 이루어졌다.
Retrieved from "https://itwiki.kr/index.php?title=지속적_연결&oldid=39781"