[HTTP] HTTP 프로토콜 패킷 분석

1. 관찰 환경 및 방법

본인은 2020년 4월 18일 토요일부터 2020년 4월 22일 수요일까지 약 6일간 Wireshark를 이용하여 http기반의 임의의 사이트에 접속하고 패킷을 분석 및 관찰했다. 본인 자택 주변의 두 군데의 카페와 자택에서 진행했고 PC는 노트북과 데스크톱을 이용했는데, 노트북은 여러 개의 WIFI를 연결하며. 데스크톱은 유선망을 이용한다. 데스크톱은 본문3번의 ‘새로 알게 된 사실’을 기술할 때 사용했다. 두 컴퓨터 모두 Windows10운영체제이고 Internet Explorer11을 사용했다.

Wireshark는 패킷을 관찰하기에 매우 최적화된 프로그램이다. 우선 시간 순으로 요청과 응답에 의한 패킷 정보들이 보기 좋게 나열되어 있다. Wireshark의 상단부를 보면 Source(패킷을 보낸 주소), Destination(패킷 도착 주소), Protocol정보, Length(패킷의 길이) 등 여러가지 항목들을 통해 ‘순서대로’ 쌓여 있는 패킷들을 정렬할 수 있었다. 필자는 Wireshark의 여러가지 기능을 사용했는데, 쌓인 패킷들을 특정 조건에 의해 검색하는 것, 패킷 정보들을 Capture하는 것, 패킷 정보들을 시각적으로 보여주는 Statistics의 I/O Graph, Endpoint등이 그것이다.

 

 

2. Protocol 분석

1) HTTP request와 response message의 header 분석

HTTP는 Hypertext Transfer Protocol로써 웹서버와 사용자의 인터넷 브라우저 사이에 문서를 전송하기 위해 사용되는 프로토콜이다. 하이퍼텍스트는 문서 중간중간에 특정 키워드를 두고 문자나 그림을 상호 유기적으로 결합하여 연결시킴으로써, 서로 다른 문서라 할지라도 하나의 문서인 것처럼 보이게 하고 참조하기 쉽도록 하는 방식을 의미한다. 또한 HTTP의 기본은 Client/Server Model이다. 즉, HTTP에서 의사소통방식은 Client가 HTTP Request를 보내면, 이에 대해 Server가HTTP Response를 하는 방식을 의미한다. 보통 Client는 브라우저로 간주한다. 다음은 http를 이용한 특정 서버의 접속과 “처음으로 주고받은” 4가지의 Request Message와 Response Message를 분석한 결과이다.

 

[그림1]

 

위 [그림1]은 Internet Explorer로 아주대학교 홈페이지를 http로 접속하고 아무것도 하지 않은 상태에서 주고받은 HTTP 메시지의 결과이다. Client PC는 필자의 노트북이며 분당선 오리역 근처의 한 카페에서 WIFI를 연결했다.

 

[그림2]

[그림1]의 No. 2131와 No. 2259의 패킷 정보를 보면 Source가 192.168.1.54라고 보여진다. 이는 [그림2]와 같이, Windows의 cmd창에서 ‘ipconfig’ 명령어를 입력하여 얻어낸 결과인 현재 Client PC가 WIFI로 접속한 IP주소와 일치했다. 따라서 Source의 주소는 WIFI를 사용중인 브라우저의 IP주소이며 HTTP요청 메시지를 보내는 주소이기도 하다. Destination에 보여지는 202.30.0.19는 HTTP요청 메시지가 도착한 주소이다. No. 2131와 No. 2255는 Source와 Destination 주소가 서로 반대로 보여진다. Wireshark에서 부여된 패킷 번호는 기본적으로 순서대로 정렬된다. 따라서 Client가 No. 2131 패킷을 요청 메시지로 보내고, No. 2255는 서버가 응답한 패킷으로 생각할 수 있다. Destination의 오른쪽 2번째 항목인 Length는 HTTP메시지의 길이를 나타낸다. No. 2131의 Request Message보다 No. 2255의 Response Message의 Length가 더 큰 것은 Response Message는 Header뿐만 아니라 Body(실질적인 Content)부분을 포함하기 때문이다.

 

① HTTP Request Message Header분석

 

이제 본격적으로 Header를 분석하도록 한다. 아래의 [그림3]은 [그림1]의 첫 번째 항목인 No. 2131에서 보여주는 ‘HTTP Request Header’이다. 두 번째 줄은 request line으로써 ‘GET’은 Server에게 Content를 ‘주세요’ 요청을 의미하는 method이고 이 외에도 POST, HEAD가 있다. ‘/’는 요청한 Content를 저장하고 있는 root directory를 의미한다. 다음에 나오는 HTTP는 요청에서 사용한 Protocol이며, 1.1은 HTTP버전을 의미한다. \r\n은 개행 문자이다.

 

[그림3]

‘Accept’를 이용한 field는 여러가지 종류가 있는데 ‘Accept-키워드’와 같이 키워드 부분을 통해 Client가 원하는 형식을 명시한다. 즉, Client가 Accept로 시작하는 여러가지 field를 통해 원하는 형식을 보내면, Server는 이에 대응하는 Response를 보내줄 수 있다. [그림3]에는 총 3가지의 Accept계열의 field가 있다. 첫 째로, [그림3]의 7번째줄에 ‘Accept’ field는 Client가 받고 싶어 하는 ‘파일 형식’들을 나열한 것이다. 즉, 현재 Client는 text/html, application/xhtml+xml등의 형식을 갖춘 파일을 받고자 함을 알 수 있다. 두 번째로 ‘Accept-Language’ field는 Client가 해석할 수 있는 언어를 명시한 것이다. 현재Client는 한국어 text를 해석할 수 있다. 마지막으로, ‘Accept-Encoding’ field이다. Server는 Content를 좀 더 빠르게 보내기 위해서 Content를 압축하여 client에게 보내는데, Accept-Encoding은 Client가 해석할 수 있는 압축방법을 명시한 것이다.

‘User-Agent’는 현재Client가 어떤 종류의 프로그램(운영체제와 브라우저 등)을 이용해 요청을 보냈는지 보여준다. [그림3]을 보면 MSIE와 Windows가 보이므로 현재 Client는 Internet Explorer브라우저와 Windows운영체제를 사용중인 것으로 해석할 수 있다. Host는 서버의 도메인 네임이 나타나는 부분으로 Host 헤더는 반드시 하나가 존재해야 한다. 그리고 Connection으로 keep-alive상태를 요청했다. 이는 한번 보낸 요청 메시지가 끊기지 않고 지속적으로 보낼 수 있게 하기위해서 Server에게 요청한 것이다. Persistent connection에 대한 설명은 2-2)에서 설명하도록 하겠다.

마지막으로 Header field ‘cookie’는 서버로부터 받은 브라우저의 쿠키 ID를 cookie필드 값으로 보내는 것이다. 이에 대한 결과로 서버는 데이터베이스에 저장된 브라우저의 쿠키 데이터를 활용하고 Client에게 더 좋은 서비스를 제공한다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있고, stateless(상태가 없는) HTTP프로토콜에서 상태정보를 기억시켜주는 역할을 해준다. 쿠키는 보통 브라우저에 의해 저장된다. Cookie를 설정할지 말지는 Client에게 선택적이고 만약 브라우저의 보안 설정에서 쿠키를 생략할 수 있다면 쿠키를 사용하지 않을 수 있다.

 

② HTTP Response Message Header 분석

 

[그림4]

[그림4]는 아주대학교 홈페이지를 관리하는 서버로부터 처음으로 받은 HTTP Response Message이다. Status line의 ‘302 Found’에서 응답코드 302는 요청한 Content가 없는 것은 아니지만 이동하였음을 의미하는 분기처리(redirect)를 보여준다. Location필드 값으로 재요청을 하면 Content를 받을 수 있다. redirection에 대해서는 2-3)에서 언급하도록 한다. ‘Content-Type’은 Server가 보내는 Content의 형식을 보여준다. 즉, Server가 현재 보내는 Content에는 text문서와 html문서를 포함하며 Character set은 UTF-8로 인코딩되어 있다. ‘Connection’ field는 위의 Request Message와 공통으로 사용되며 여기서는 Request Message에서 보낸 Connection에 대한 응답이다. 따라서 Server는 ‘연결을 끊지 않을 테니 요청을 계속 보내도 된다’라는 응답을 한 것으로 해석된다. ‘Date’또한 Request, Response Message에서 공통으로 사용되며 HTTP Message가 만들어진 시각을 의미한다. ‘Pragma: no-cache’는 캐시데이터를 사용하기 전에 서버로 요청을 보내 유효성 검사를 강제한다. PHAROSAGENT는 중개서버를 명시한다. 아주대학교 홈페이지는 junggak-w1이라는 중개사를 이용중인 것으로 보인다. Location은 앞서 말한 ‘302 Found’에서 이동된 Content의 위치를 알려준다. Client는 서버가 알려준 Location으로 재요청 메시지를 보낼 수 있다. 

 

‘Cache-Control’ 필드 값으로 ‘no-cache’가 보이는데, 앞서 말한 ‘Pragma: no-cache’와 같은 의미로 해석할 수 있다. 쉽게 말하자면, 캐시데이터를 사용하기 전에 서버에게 해당 캐시를 써도되는지 물어보는 것이다. 추가로 말하자면 Pragma 필드는 Cache-Control필드가 등장하기 전에 대체자로 사용되었다. ‘Expires’ 필드는 캐시에 존재를 제어하는 기본적인 방법으로 사용된다. 즉, 응답 Content가 언제 만료되는지(언제 캐시에서 초기화 되는지)를 나타내며, Cache-Control의 max-age또는 s-max-age가 있는 경우 이 헤더는 무시된다. 캐싱에 대해서는 2-4)에서 다루도록 한다. 마지막으로 ‘set-cookie’ 필드가 나오는데, 이는 응답 헤더(Server)에서만 사용되는 필드이다. 브라우저(Client)로부터 받은 쿠키 요청(cookie)을 서버는 set-cookie를 헤더에 보내서 응답할 수 있고, 서버(정확히 말하자면 에이전트 서버 junggak)에서 사용자 브라우저(Client)에 ‘쿠키정보’를 전송하기 위해 사용된다. 브라우저(Client)는 이를 저장하고 다음에 동일한 서버에 접속요청을 할 때, cookie필드 값에 쿠키ID를 전송하여 쿠키데이터를 이용할 수 있다. Set-cookie의 필드 값은 cookie-name = cookie-value 형식으로 구성된다. ‘Content-Length’ 필드는 응답으로 보내는 Content의 데이터 크기를 말하며 단위는 Byte이다. 현재 Server는 827byte크기의 Content를 보냈다고 볼 수 있다.

 

2) Persistent connection

① persistent connection과 pipelining

 

HTTP Request들은 ‘연속적이고 순차적’이다. HTTP / 1.0에서는 하나의 HTTP Request를 socket에 write를 하고, Server의 Response를 받아 다음 Request를 보내는 방식으로 웹이 동작한다. 즉, HTTP요청 한 번을 하기위해, TCP연결도 한 번해야 한다는 것이다. 이런 방식의 전송은 불필요한 RTT증가로 이어지고 Network Latency(지연속도)에 있어서 큰 비용이 요구된다. 또한, 요청과 응답에 있어서 연결을 맺고 끊음을 반복하는 것은 Server Resource면에서도 좋지 않다.

HTTP/1.0버전 발표 이후, 이러한 문제점을 보안하기 위해 클라이언트와 서버간 요청과 응답을 ‘어떻게 빠르게 할 수 있을까’에 대한 연구가 이루어졌고, 대표적으로 ‘Persistent Connection’과 ‘Pipelining기법’이 HTTP/1세대부터 도입되었다.

첫 번째는 Persistent Connection기술이다. web의 초창기에는 전달해야 하는 사이트의 Content가 그리 크지도 많지도 않았기 때문에 한 번의 TCP연결 사용으로 인한 부담이 크지 않았다. 하지만 웹사이트의 Content(이미지파일을 포함한 멀티미디어)가 늘어나면서 TCP연결의 ‘재사용’이 필요하게 되었다.

 

[그림5]

[그림5]는 Multiple Connection과 Persistent Connection을 보여준다. Multiple Connection은 HTTP초창기 세대를 설명한다. 오브젝트 하나를 받기 위해 한 번의 TCP연결의 맺음과 끊음이 요구되었다. Persistent Connection을 보면, 한 번의 TCP연결에 필요한 오브젝트들을 모두 요청하고 얻어오는 방식으로 Multiple Connection보다 빠른 요청, 응답이 가능해졌다.

 

[그림6]

두 번째로 HTTP / 1.1에서는 Persistent Connection과 더불어, ‘HTTP Pipelining’기술이 도입되었다. HTTP Pipelining기술 도입 이전에는 보낸 요청에 대한 응답이 도착한 후에야 비로소 다음 응답을 보낼 수 있었지만, HTTP Pipelining기술 도입 이후에는 ‘연속적인 요청’이 가능해졌다. 이는 Network Latency를 줄이고 좀 더 빠른 HTTP 요청 및 응답을 가능케 했다.

기본적으로 HTTP Message는 순번이 매겨져 있지 않아 응답이 순서 없이 오면 순서에 맞게 정렬할 방법이 없다. 이로인해 HTTP응답은 요청 순서와 같게 와야 한다는 제약이 있다. Pipelining기법을 도입하더라도 기존의 방식보다는 빠른 결과를 얻을 수 있다. 하지만 응답에 대한 처리는 순차적으로 이루어지며 후순위 요청에 대한 응답은 지연될 수밖에 없는 ‘Head of Line Blocking’문제점을 갖는다. 따라서 HTTP / 1.1의 웹서버는 Persistent Connection을 하면서도, 각 연결 당 요청과 응답의 순서가 보장되는 통신을 한다.

 

② Persistent Connection중 Pipelining에 관한 사례 분석

 

모든 종류의 HTTP요청이 파이프라인으로 처리될 수 있는 것은 아니다. 파이프라인 기법은 ‘GET’, ‘HEAD’, ‘PUT, DELETE’ method의 경우에서만 가능하다. Request Message의 Connection 필드 값이 ‘keep-alive’라면 Persistent Connection을 Client가 Server에게 요청한 것으로 볼 수 있지만 Server는 이를 무조건 따를 의무가 없다. 하지만 Response Message의 Connection필드 값에도 ‘keep-alive’가 명시되어 있다면, Server는 Client가 요구한 Persistent Connection을 받아들였음을 의미한다. 더불어 Keep-Alive 필드 값으로 max와 timeout값을 설정하여 응답하는데 max가 갖는 값의 수만큼의 트랜잭션이 처리될 동안 Connection을 유지하거나, timeout(단위는 초)동안 Connection을 유지하라는 의미로 해석할 수 있다. 다음은 법무부 홈페이지를 방문했을 때 결과의 일부분이다.

 

[그림7]

우선 현재 대표적으로 알려진 HTTP Pipelining을 적용한 브라우저는 ‘Opera’라고 한다. 따라서 필자는 Opera브라우저를 통해 법무부 홈페이지를 방문했다. [그림7]에서 밑줄 친 부분을 보면 요청 메시지가 ‘연속하여 발생’했음을 확인할 수 있다. 그리고 밑줄 친 요청 메시지들은 “모두 같은 Source Port번호를 통한 요청”이었다. 또한 HTTP버전이 1.1인 점과, ‘GET’ method를 사용했다는 점에서 HTTP Pipelining기법을 사용했음을 알 수 있다. 물론, 밑줄 친 모든 요청 메시지 모두 Connection필드 값으로 ‘keep-alive’를 명시함으로써 Persistent Connection을 기반으로 Pipelining기법을 사용하고 있음을 알 수 있다.

Client가 ‘GET’ method가 아닌 ‘POST’ method로 요청을 보낼 경우 Pipelining이 가능할까? ‘POST’ method를 이용한 요청은 반복해서 보낼 경우 문제가 생기는데, 이러한 요청은 파이프라인을 통해 보내면 안된다. 에러 발생시 파이프라인을 통한 요청 중 어떤 것들이 서버에서 처리됐는지 Client가 알 방법이 없기 때문이다.

 

3) Redirection 사례

Redirection은 실제 Resource또는 Content가 다른 URL에 위치하고 있는 상태에서 링크를 존속시키기 위한 기술이다. 요청한 Content가 다른 곳에 있을 때 발생하며 3xx와 같이 ‘3’으로 시작하는 상태코드가 나타난다면 Redirection이 발생할 수 있음을 알 수 있다. 브라우저는 Server로부터 받은 새로운 Location(URL)으로 HTTP 재 요청 메시지를 보내고 Content를 받아올 수 있다.

 

[그림8]

[그림8]은 http://web.archive.org/ 에 접속하였을 때의 HTTP요청과 응답을 보여준다. 처음요청에 대한 응답을 보면 Status line에 ‘302 FOUND’라는 문구가 보인다. 이는 해당 Content가 다른 곳으로 이동했음을 의미하며 Location 필드 값으로 Content가 있는 위치를 알려준다. 그 후, Client는 Server로부터 받은 Location에 http요청을 다시 보낸다.

이 외의 Redirection의 활용은 다양하다. 예를 들어, 포털사이트 ‘다음’의 한 카페에 회원들만 볼 수 있는 글에 로그인을 하지 안은 채 접속을 할 경우, 다음 서버는 Status line에 3으로 시작하는 문구와 함께 Redirection을 알릴 것이다. Location에는 경고창을 띄우는 URL이나 로그인을 권하는 URL을 보낼 것이고, 응답을 받은 Client는 응답 메시지를 보고 해당 URL로 HTTP재요청을 보낼 것이다.

 

4) Web caching 기능

Caching은 Client와 Server간에 Proxy server를 두어 Client가 요청 시 Server까지 가지 않아도 Content를 빠르게 받아올 수 있는 방법이다. Proxy server는 Client입장에서는 Server이고, Server입장에서는 Client로 동작한다. Proxy server에는 ‘자주 그리고 최근에’ 사용된 Content(Objects)를 두는 것이 합리적이다. 그리고 Caching기법의 장점으로 Server는 받는 요청의 수가 줄어들고 각 기관들의 access link로 흐르는 traffic을 원활하게 해준다.

하지만 서버에서 Content의 내용을 수정한다면 캐시에 저장된 복사본은 최신의 것이 아니다. 따라서 Client는 이러한 사실을 확인하지 않고, 수정되지 않은 캐시의 데이터를 갖고 간다면 문제가 된다. 이 문제는 요청과 응답 메시지로 해결할 수 있다. Client는 해당 데이터가 최신의 것이 맞는지 확인하는 요청 메시지를 Original Server에게 보내고, Original Server는 응답 메시지로 결과를 알려준다. 이러한 요청 메시지도 Original Server까지 보내야 하지만, 요청 메시지의 크기는 매우 작다. 그리고 응답 메시지도 매우 작거나 아니면 새로 갱신된 데이터를 보내주는 방식이기 때문에 delay가 적게 발생한다.

 

① Caching 데이터가 최신의 것일 경우(캐시데이터와 서버데이터가 같을 경우)

 

[그림9]

Client가 찾는 데이터가 캐시에 저장되어 있다 하더라도 그 데이터가 최신의 것이 맞는지 확인해야 한다. 이때 Client는 요청 메시지에 ‘If-Modified-Since’필드를 이용하여 찾는 데이터가 Server에서 갱신되었는지 확인하고 Server는 그 데이터가 최신의 것이 맞다면 [그림9]와 같이 응답 메시지의 Status line에 ‘304 Not Modified’를 보낸다. 또한 응답 메시지에 ‘Last-Modified’필드 값으로 마지막에 수정된 날짜를 Client에게 알려주었다. 이 경우 요청 메시지에서 보낸 ‘If-Modified-Since’필드 값과 응답 메시지에서 보낸 ‘Last-Modified’의 필드 값은 같은 값을 갖는다. 이 외에 Last-Modified필드를 보내지 않는 경우도 있었다.

 

② Server의 데이터가 갱신되어 Caching 데이터가 최신의 것이 아닐 경우

 

[그림10]

[그림10]은 서울시교육청 홈페이지의 자주묻는질문 베너의 URL을 접속했을 때 오고 간 요청 응답 메시지의 헤더부분이다. Server의 Content Data가 갱신되어 Cache에 저장된 Content가 최신의 것이 아닐 경우의 예를 보여준다. 우선 요청 메시지를 보면 ’If-Modified-Since’필드 값을 통해 2020년 4월 14일 12:40:14 이후로 Server의 데이터가 갱신되었는지 묻는 요청 메시지를 보낸다. 응답 메시지를 에서 Status line의 ‘200 OK’상태를 보아 서버의 데이터가 갱신되었음을 알 수 있고, 이 경우 서버는 갱신된 데이터를 바로 Client에게 보내준다. 추가적으로 응답 메시지의 ‘Last-Modified’필드 값은 가장 마지막 Content가 수정된 날짜와 시각인데, 응답 메시지에서 보낸 ’If-Modified-Since’필드 값과 다른 값(정확히 말하면 서버가 더 최신의 시간정보)을 갖으므로 캐시의 데이터는 최신의 것이 아니다. 이 경우, 서버는 응답으로 최신의 Content를 보낸다.

 

3. 새로 알게 된 지식

 

HTTP Message는 순번이 매겨져 있지 않아 응답이 순서 없이 오면 순서에 맞게 정렬할 방법이 없다. 따라서 HTTP응답은 요청 순서와 같게 와야 한다는 제약이 있다. 또한 응답을 받더라도 이에 대한 처리는 받은 응답부터 순차적으로 이루어지며, 결국 뒤늦게 보낸 요청에 대한 응답은 지연될 수밖에 없는 ‘Head-of-Line Blocking’문제를 갖는다. 이러한 문제점은 파이프라이닝 기법을 사용했을 때 발생한다.

HTTP는 메시지를 온전하게 보내기 위해서 Transport Layer의 TCP를 사용한다. 그리고 ‘TCP연결’ 시 장치들 사이에 논리적인 접속을 성립(establish)하기 위해 3-way handshaking을 사용한다는 것을 알게되었다. 3-way handshaking은 TCP/IP 프로토콜을 이용하여 통신하는 응용프로그램(브라우저)이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하고 상대방 컴퓨터와 사전에 세션을 수립하는 과정이다.

 

[그림11]

 

Client에서 웹 서버로 연결 최초시도 시 먼저 SYN(synchronize sequence number)패킷을 보낸다. SYN패킷을 보낸 Client는 SYN-SENT상태(SYN패킷을 받은 상태)가 된다. 이때 Server는 Listen상태(포트가 열린 상태로 연결 요청 대기중)로 서비스가 가능한 상태여야 한다. 이 다음, Listen상태에서 Client로부터 SYN패킷을 받으면 이에 대한 응답으로 SYN+ACK패킷을 Client에게 전송한다. Server는 Client주소에 대해 SYN-Received상태로 전환한다. 그리고 Server로부터 SYN+ACK패킷을 받으면 Client는 Established상태(연결 확인상태)가 되며 연결을 확인한다. 마지막으로 Client는 Server에게 ACK(acknowledgment)패킷을 보낸다. Server는 ACK패킷을 받고 Client IP에 대한 포트 Established상태가 된다. 이렇게 TCP연결을 하고 나서 HTTP메시지를 전송할 수 있다.

 

[그림12]

[그림12]는 ‘최초의 TCP연결 시’ 3-way handshaking을 방식을 이용하여 연결하는 것을 확인할 수 있었고 비로소 HTTP 요청 메시지가 전송되었음을 알 수 있었다. 3-way handshaking이 TCP최초 ‘연결’ 시 사용된다면 4-way handshaking은 TCP세션을 종료하기위해 수행되는 방법이다.

여기서 알게 된 사실은 다음과 같다. Persistent Connection 도입 이전에는 HTTP 요청과 응답 메시지 한 번을 하기 위해서 복잡한 TCP연결의 맺고 끊음 한 번이 필요했다. 하지만 Persistent Connection도입 이후에는 최초연결 시에 TCP연결을 하고 필요한 요청과 응답이 모두 오고 간 뒤, TCP연결을 종료한다는 것이다. 결국 Persistent Connection과 Persistent Connection을 기반으로 하는 Pipelining이 delay를 매우 감소시켜줬을 것임을 느끼게 되었다.

또한 필자는 P2P application에서 주고받는 메시지를 확인하고 싶었고, 토렌트에서 임의의 파일을 다운받는 동안 Wireshark에서 감지를 시작하였다. 이번에는 유선의 데스크톱을 이용하였고 IPv4주소는 192.168.0.9이다.

[그림13]

[그림13]은 토렌트를 이용하여 파일을 다운로드할 때 Wireshark결과의 일부이다. BitTorrent라는 프로토콜을 사용했고 다양한 목적지를 갖을 수 있음을 알게되었다.

[그림14]

[그림14]는 Wireshark에서 상단부의 Statistics -> Endpoints의 결과이다. 이는 나와 연락한 다른 peer들의 IP주소를 보여주며, p2p application을 이용하는 개인과 개인이 직접 연결되어 파일을 공유한다는 사실을 확인했다.

 

Reference

• 위키피디아, https://en.wikipedia.org/wiki/HTTP_persistent_connection
• 위키피디아, https://en.wikipedia.org/wiki/HTTP_pipelining