HTTP Transaction 구조
기본적으로 HTTP Transaction은 FTP연결 -> GET/POST 요청 -> RESPONSE -> FTP연결 해제 순서이다. 그러나, 연이어서 파일을 GET하거나 POST할것이라면 FTP을 반복적으로 연결하고 해제하는것이 비효율적이게 된다. 아래의 그림을 보면 연이어서 정보를 주고받아야 하는 상황인데도 불구하고 TCP의 연결과 종결이 불필요하게 많이 이루어짐을 확인할 수 있다. 이런 부분의 성능향상을 이루고자 한 형태가 Persistent HTTP이다.
Persistent HTTP
Persistent HTTP는 필요시까지 TCP연결을 유지함으로 TCP 연결/해제에 필요한 자원을 절약하는 형태이다. FTP 연결/해제 또한 비용이 드는 부분이기 때문에 필요한 요청이 다수있다면, FTP 연결상태를 유지해놓는 것이 효율적이다.
그러나, Persistent HTTP의 형태도 만족할 수 있는 형태는 아니다. 위에서는 이미지를 차례차례로 하나씩 받아오는 형태이기때문에 이런부분 또한 시간 낭비가 이루어진다. 이는 동사무소에 가서 첫번째 서류를 요청하고 받고, 그 다음 서류를 다시 요청하고 받고, 다시 그 다음 서류를 요청하고 받는 형태와 동일하다. 이 작업을 효율적으로 처리하려면 필요한 요청을 한꺼번에하고 처리를 받는것이 필요하다.
Pipelined HTTP
Pipelined HTTP는 필요한 요청을 한꺼번에 보내는 형태이다. 주의할 점은, 필요한 요청이 무엇인지 파악하기위해 HTML문서는 우선적으로 한번 봐야한다는 것이다. HTML문서를 읽으면서 어떤 요소들을 동시요청할지 파악한다. 파악이 된 후에, 필요한 자원들을 동시요청하고 동시응답받게 된다.
성능
이제 위 형태들의 성능을 파악해볼수 있는데, 성능은 크게 지연시간과 전송률로 파악할 수 있다. 이 두가지는 비례하는 개념은 아니고 따로 이야기해야하는 개념이다.
1) 지연시간
지연시간은 패킷을 보내기 시작한 시점에서 패킷을 받기 시작한 시점까지 걸리는 전송 지연시간을 의미한다. 거리가 멀수록 지연시간이 점차 늘어나는데, 이는 패킷을 처리해주는 장비를 거칠수록 시간이 증가하기 때문이다. 우리는 지금까지 HTTP Transaction을 표시할때 선을 사선으로 표시했는데, 이런 지연시간이 존재하기 때문에 Transaction을 사선으로 표기해온 것이다.
2) 전송률
전송률은 단위시간 (초)당 전송되는 데이터의 양을 의미한다. 예를들어, 1MB를 보내는데 4초가 걸렸다면, 1초당 250KB의 양을 보낸 것이다. 이처럼 단위시간당 얼마만큼의 패킷을 전송할 수 있는지 나타내는 지표가 전송률이다.
하나의 문제를 예시로 들어보자.
끝단간 지연시간이 100ms이고, 전송률이 100MB/s인 네트워크에서 1MB를 전송하여 수신을 완료하는데 걸리는 시간은?
이때 ms는 1/1000초를 의미한다. 1MB를 100MB/s의 전송률로 전송하면 패킷이 전송되는데 소요되는 시간은 1/100초다. 따라서, 패킷을 보내기 시작한 시점에서 패킷을 받기 시작하기 까지 걸리는 시간 0.1초와 패킷이 전송되는데 소요되는시간 0.01초를 더하면, 총 0.11초(110ms)가 소요된다.
HTTP 형태에 따른 성능 차이
몇가지 가정을하고 기본적인 HTTP, Persistent HTTP, 그리고 Pipilined HTTP의 성능을 비교해보자.
* 가정
1) 끝단간 지연시간은 100ms
2) 전송률은 100KB/s
3) 전송받고자하는 정보는 HTML문서와 3개의 이미지 이며, HTML문서는 1KB이고 이미지당 크기는 10KB
4) HTTP 헤더는 Request와 Response모두 1KB라고 가정
5) TCP 연결/종결시간은 각각 400ms, 200ms를 가정
1) 기본적인 HTTP
가장먼저 기본적인 HTTP에서 HTML문서를 요청하고 응답받는 경우부터 살펴보자 (HTML문서와 3개의 이미지, 총 4개를 받아야 하는 상황).
기본적인 HTTP는 TCP 연결 -> GET/POST -> Response -> TCP 종결이 하나의 HTTP Transaction이 된다. 때문에 각각의 요청마다 TCP 연결/종결시간을 기본적으로 고려해야한다. 즉, 하나의 요청마다 400ms + 200ms = 600ms의 시간이 소요되는것이다. 따라서, HTML 문서를 주고받을때도 TCP 연결/종결시간을 고려하면 기본적으로 600ms의 시간이 소요된다.
끝단간 지연시간은 100ms라고 했으므로, 주고 받는 경우를 각각 고려한다면 총 지연시간은 200ms가 된다. 그리고 클라이언트가 서버에게 보내는 Request HTTP 헤더와 서버가 클라이언트에게 보내는 Response HTTP 헤더의 크기는 각각 1KB이므로 헤더가 오고가는 시간은 총 1/100초, 즉 10ms가 된다. 마지막으로, Response할때 1KB 크기의 문서도 함께 보내므로 10ms의 시간까지 고려해주면 된다.
이를 모두 고려했을때, 기본적인 HTTP에서 HTML문서를 요청하고 응답받기까지 걸리는 시간은 830ms가 된다. 여기서 이미지를 받는 경우를 고려한다고하면 HTML문서의 크기 1KB가 아닌, 이미지 크기 10KB를 고려해주면 된다. 830ms - 10ms + 100ms = 920ms 이므로 이미지 하나를 요청해서 응답받는 시간은 920ms가 된다. 따라서 HTML 문서하나에 소요되는 시간 830ms, 그리고 이미지 세개에 소요되는시간 920 * 3 ms를 더해주면 총 2760ms + 830ms = 3590ms가 소요된다.
2) Persistent HTTP
위에서도 설명했듯이, Persistent HTTP는 연이어 받을 정보가 존재한는 경우 TCP연결을 유지하는 형태이다. 위에서 기본적인 HTTP같은 경우에는 총 4번의 TCP 연결/종결 사이클이 존재했다. 이 TCP 연결/종결에만 소요되는 시간은 600 * 4ms = 2400ms 이다. 그러나 Persistent HTTP는 1번의 TCP 연결/종결만을 필요로하기 때문에, 위에서 구한 값에서 3번의 TCP 연결/종결에 걸리는 시간을 차감해주면 된다. 따라서 3590ms - 1800ms = 1790ms가 Persistent HTTP에서 소요되는 시간이다.
3) Pipelined HTTP
마지막으로 Pipelined HTTP에 대해 살펴보겠다. Pipelined HTTP는 필요한 요청을 한꺼번에 보내고 응답받는다는 특성이 있다. 그리고 자원을 받는 동시에 다른 자원에 대한 요청을 보내는 것이 가능하다.
HTML 문서 획득
Pipelined HTTP는 동시요청이 가능하다. 그러나, 동시요청을 하기 위해서는 서버로부터 HTML문서를 먼저 획득해야 한다. 때문에 먼저 HTML 문서를 획득하기 까지의 시간을 생각해보자.
가장먼저 TCP 연결소요시간 400ms이 필요하다. 그리고 Request/Response 각각의 지연시간 100ms를 고려해주면 200ms가 추가로 소요된다. 마지막으로 클라이언트에서 헤더를 전송하기 까지 걸리는 시간 10ms와 서버에서 클라이언트에게 헤더와 HTML문서를 전달하는데 걸리는 시간 20ms를 고려해준다. 이를 총합하면 HTML 문서를 요청하고 응답받는데까지 걸리는 시간은 630ms 이다.
630ms가 소요된 시점 HTML에서 이미지 정보가 모두 파악되었으므로, 동시요청할 준비가 되어있다.
이미지 동시요청/획득
다음으로 이미지 3개를 획득하고 TCP 종결까지의 시간을 생각해보자. 이 부분에서는 자원을 받는 동시에 다른 자원에 대한 요청을 보낼수 있다는 점을 고려해야 된다.
아래에 표현된 '경과시간'은 Client가 HTML문서를 획득한 시점에서의 경과시간을 나타낸다. 서버가 클라이언트로부터 그림1에 대한 요청을 받기까지 걸리는 시간은 110ms이다 (지연시간 + 패킷전송시간). 110ms가 소요되고 난 후에는, 서버가 그림 2에 대한 요청을 받는 동시에 그림 1에대한 문서를 클라이언트에게 넘겨준다 (Pipelined의 특성). 결론적으로 이렇게 자원을 받음과 동시에 자원을 보내는 특성때문에 Pipelined HTTP가 Persistent HTTP보다 시간을 절약할 수 있게 되는 것이다.
이런 특성을 고려해 이미지 3개를 모두 획득하는데까지 걸리는 시간은 540ms 이 도출되고, 이에 TCP 종결시간 200ms 를 더해주면 740ms가 소요된다. HTML 문서획득까지 걸린 시간이 630ms 이었으므로, 이에 740ms를 더해주면 총 소요시간은 1370ms가 된다.
'네트워크' 카테고리의 다른 글
[네트워크] Web Cache (0) | 2023.01.24 |
---|---|
[네트워크] Cookie (0) | 2023.01.21 |
[네트워크] HTTP 개요 (0) | 2023.01.10 |
[네트워크] TCP/UDP (0) | 2023.01.07 |
[네트워크] 프로세스간 통신 (0) | 2023.01.01 |