2021. 8. 4. 18:47ㆍ[ Basic ]/# 네트워크
1. 개요
Application Layer와 Network Layer 사이에 존재하는 Transport Layer는 네트워크의 계층구조에서 핵심이다. Application 관점에서 보면 process들이 동작하는 호스트들이 직접 연결된 것처럼 보이는데, 이는 Transport Layer Protocol이 제공한다. 즉, end사이의 IP전달 서비스가 UDP와 TCP가 있음으로써 end사이의 두 프로세스 간의 전달 서비스로 확장된다. 여기서 transport multiplexing, demultiplexing이 활용된다. 일반적으로 Transport Layer단계에서 생성된 패킷을 세그먼트, Network Layer에서 생성된 패킷을 데이터그램이라고 부른다.
우선 UDP traffic을 관찰하기 위해 DNS를 분석할 것이고, TCP는 어떻게 연결을 맺고 데이터를 교환하는지, 그리고 연결은 어떻게 종료하는지 알아본다. 또한, TCP retransmission이 발생하는 경우에 대해서 알아본다. 마지막으로 패킷들을 관찰하면서 새로 알게 된 사실을 정리했다.
2. 관찰 방법
5월 25일부터 4일간 wireshark프로그램을 이용한 패킷 캡쳐를 진행했다. PC는 개인 노트북을 이용했다. TCP연결을 확인할 때는 Statistics의 -> Flow Graph를, TCP Retransmission을 확인할 때에는 Statistics -> TCP Stream Graphs -> Time Sequence (Stevens)를 활용했다. 해당 IP주소에 대한 정보를 알기 위해 www.iplocation.net 홈페이지에 IP주소를 검색했다.
3. Traffic 분석
1) UDP (User Datagram Protocol) 분석
UDP는 User Datagram Protocol로써 전송 방식은 너무 단순해서 서비스의 신뢰성이 낮고, 데이터그램 도착 순서가 바뀌거나, 중복되거나, 심지어는 통보 없이 누락시키기도 하여 데이터가 목적지 프로세스에 도착하는 것을 보장하지 않는다. 또한 TCP처럼 handshaking 방식을 하지 않아서(비연결형 전송), 상대방이 세션에 준비되었는지 확인하지 않는다. 이러한 특징은 UDP는 간단한 오류 검사 기능을 제외하고는 비신뢰적인 IP프로토콜에 특별한 무엇도 추가하지 않기 때문이다.
DNS(Domain name system) 프로토콜은 UDP상에 수행되는 어플리케이션 계층 프로토콜 중 하나이다. www.google.com과 같은 호스트 네임은 4byte로 구성된(IPv4기준) IP주소로 식별된다. 이렇게 호스트 네임을 IP주소로 변환해 주는 서비스가 인터넷 DNS가 지원한다. DNS는 DNS 서버들의 계층구조로 구현된 분산 데이터베이스이고, 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다. 포트번호는 53을 이용한다.
[사진1]은 google.com에 접속하였을 때 DNS 메시지를 보여준다. No 78 패킷은 호스트에서 DNS 어플리케이션이 query(질의)를 생성하고 DNS 질의 메시지를 작성했음을 보여준다. 또한 [사진1]에서 해당 DNS의 stream번호 19(udp.stream eq 19)로 검색했을 때 2개의 결과만 나왔다. 따라서 UDP 연결 수립을 위한 어떠한 interaction없이 바로 애플리케이션 데이터를 보내고 있다. 따라서 목적지 end에 존재하는 UDP개체와 호스트의 UDP는 어떠한 handshaking도 수행하지 않음을 알 수 있다.
 [사진2] |
 [사진3] |
[사진2]와 [사진3]과 같이 UDP는 각각 16bit로 구성된 4개의 header field(8byte)를 만을 갖는다. Source port, Destination port, Length, Checksum이 그것이다. 이처럼 8byte로 구성된 간결한 헤더를 갖으면 속도나 오버헤드 측면에서는 장점이 될 수 있지만 신뢰성이 떨어진다는 단점도 존재한다.
[사진2]는 no 78패킷의 상세정보를 보여준다. [사진2]에서는 애플리케이션 계층 프로토콜 DNS에서 생성된 질의 메시지가 트랜스포트 계층 프로토콜인 UDP에게 메시지가 넘어갔고, UDP는 받은 메시지에 헤더 필드를 추가한 후에 최종 세그먼트를 네트워크 계층에 넘겨주었음을 알 수 있다. 네트워크 계층은 UDP 세그먼트(transport 계층에서의 패킷)를 데이터그램(네트워크 계층에서의 패킷)으로 캡슐화하고 네임 서버에 데이터그램을 전송한다. 이때, 질의 호스트에서의 DNS 애플리케이션은 질의에 대한 response를 기다린다.
[사진3]은 질의에 대한 response를 보여준다. [사진2]와 [사진3]을 보면, UDP는 checksum과 timestamp와 같이 아주 간단한 정도의 에러 체킹 만을 한다는 점을 알 수 있다. stream index는 wireshark에서 UDP 또는 TCP연결을 추적하거나 분석하기 쉽게 하기 위해 연결 시작부터 종료까지 하나의 stream으로 구분한 번호이다. 중요한 사실은 TCP와 다르게, UDP는 Sequence Number와 Acknowledgement Number와 같은 정보가 없는 것으로 보아, 패킷의 순서번호와 확인 응답과 같은 절차는 지원하지 않는다는 점이다. 만약 질의나 응답메시지를 분실하여 질의한 호스트가 응답을 받지 못하면 질의를 다른 네임 서버로 보내거나 요청한 애플리케이션으로 응답을 수신할 수 없다는 것을 알린다.
그렇다면 왜 많은 어플리케이션들이 신뢰적인 TCP보다 비신뢰적인 UDP를 사용할까? 신뢰적인 데이터 전송 서비스를 제공하는 TCP가 그렇지 않은 UDP보다 항상 더 좋다고 말할 순 없기 때문이다. 따라서 UDP는 다음과 같은 장점을 갖는다.
첫 번째로, 비연결형 특징을 갖는 점은 장점이 될 수 있다. 밑에서 설명하겠지만 TCP는 연결을 위해 복잡한 3-way handshaking을 이용한다. 하지만 UDP는 이러한 사전준비가 필요 없다. 따라서 UDP연결을 위한 어떠한 지연도 발생하지 않는다. “이러한 이유는 DNS가 TCP가 아닌 UDP에서 동작하는 이유 중 하나이다”. 또한 TCP는 세그먼트 당 20byte의 헤더 오버헤드를 갖으며 UDP는 8byte의 헤더 오버헤드를 갖으므로 빠르게 주소가 매핑되어야 하는 DNS에서는 UDP가 적합하다.
두 번째로, 애플리케이션에서 데이터를 언제 보낼지에 대한 제어가 가능하다는 점이다. TCP가 갖고 있는 congestion control(혼잡제어)는 링크가 과도하게 혼잡해질 때 트랜스포트 계층 TCP의 sender가 보내는 패킷을 조절하는 것인데, 이 과정에서는 수신 여부를 확인응답(ACK)할 때까지 세그먼트를 재전송한다. 실시간 스트리밍과 같은 애플리케이션은 도착하는 비율에 민감하여 크게 지연되는 패킷 전송을 원하지 않을 수 있다. 또한 약간의 데이터 손실은 허용할 수 있는 경우라면 더욱 UDP가 적합하다. 이러한 애플리케이션은 UDP를 이용하여 UDP 세그먼트 외에 필요한 기능을 추가 구현하는 방식으로 사용할 수 있다.
세 번째로 UDP는 연결상태(connection state)를 유지하지 않는다는 점이다. TCP에서 연결 상태를 유지하는 것은 수신, 송신 버퍼와 Sequence Number, Acknowledgement Number parameter를 포함한다. 즉, sender와 receiver에게 모두 부담이다. UDP는 이러한 상태 정보를 기록하지 않으며 이로 인해 UDP를 사용하면 더 많은 클라이언트를 수용할 수 있다.
2) TCP 분석
TCP를 사용하는 애플리케이션 계층 프로토콜은 SMTP, Telnet, FTP외에도 여러가지가 있지만, 필자는 HTTP가 TCP를 이용한 경우에 대한 패킷을 조사했다.
- connection setup 단계에서 교환하는 TCP segment header 분석
[사진4]는 정부24(gov.kr)에 http로 접속했을 때 처음으로 보여지는 TCP패킷 결과이며, [사진5]는 정부24의 웹서버의 IP주소를 검색한 결과이다.
No 1526 패킷은 클라이언트 어플리케이션 프로세스가 서버의 프로세스와 TCP연결을 설정하기를 원한다고 클라이언트의 TCP에게 먼저 말하고 클라이언트의 트랜스포트 계층에서 서버의 TCP와 TCP연결을 설정(초기화)을 요청하는 과정이다. 연결을 초기화하는 프로세스를 클라이언트 프로세스, 이때 연결 요청을 받는 프로세스를 서버 프로세스라고 한다. [사진6]은 no 1526 패킷의 상세 정보이다. 이때 SYN플래그를 1로 설정하며 32bit로 구성된 임의의 sequence number를 설정하여 보낸다. wireshark에서 순서번호 0은 상대적인 순서번호를 보여주며 실제로는 32bit로 구성된 임의의 숫자이다. 또한 이 패킷에는 date를 포함하지 않으며 header length가 32byte인 것으로 보아 기본 20byte header에 option이 12byte 추가되었다. 이 시점은 클라이언트가 CLOSED상태에서 SYNSENT상태가 된다.
[사진7]은 no 1527의 패킷 상세 정보를 보여준다. 이전 과정의 세그먼트를 서버가 받았다면 서버는 [사진7]과 같은 세그먼트로 응답한다. ACK플래그를 set하고 Acknowledgement Number를 클라이언트의 sequence number에 1을 더하여 보내며 클라이언트의 패킷을 받았음을 알린다. Acknowledgement Number역시 상대적인 숫자로 보여주고 있다. 서버 역시 TCP 세션을 클라이언트에게 요청하기 위해 SYN플래그를 set했고 임의의 순서번호(상대적으로는 0)를 설정했음을 알 수 있다. 이 패킷을 클라이언트가 받는다면 클라이언트는 이 패킷을 받는 시점이 TCP 연결을 확신하는 시점이 된다. 따라서 클라이언트는 ESTABLISHED 상태가 된다. 이 세그먼트 역시 기본 20byte의 header에 12byte의 option이 붙었음을 알 수 있었고, 첫 번째와 두 번째 과정의 세그먼트에는 페이로드가 없다. 즉, 서버와 클라이언트 모두 애플리케이션 계층의 데이터를 보내지 않았다.(아직 세션이 확립되지 않았으므로)
[사진8]은 no 1528 패킷의 정보이다. 서버로부터 SYN플래그가 set된 요청 패킷을 받았고 이에 대한 응답을 보내는 과정이다. 서버로부터 받은 sequence number에 1을 더한 Acknowledgement Number와 ACK 플래그를 set하여 서버에게 보낸다. 이 패킷을 서버가 받는다면, 이 패킷을 서버가 받는 시점이 서버가 TCP연결을 확신하는 시점이다. 이후 클라이언트는 애플리케이션 데이터가 포함된 세그먼트를 보낼 수 있고, 혹은 이 패킷(no 1528)에 포함시켜 보낼 수도 있다.
- connection 종료 단계에서 교환하는 TCP segment header 분석
125.209.230.167는 네이버의 서버의 IP주소이며 네이버 서버와 클라이언트가 4-way handshaking 방식을 이용하여 TCP connection을 종료하는 과정을 보여준다. No 58 패킷은 네이버 서버가 먼저 TCP연결을 종료하고자 TCP header의 FIN과 ACK플래그를 SET하여 전송하며, 이는 TCP연결 종료를 요청한 것이다. No 59 패킷은 no 58 패킷을 받은 클라이언트가 요청에 대한 응답으로(FIN에 대응하여) ACK플래그를 set하고 ACK번호를 포함하는 패킷을 전송한다. 이 패킷을 받은 네이버 서버는 클라이언트의 FIN을 기다리는 상태가 되며, 이 시점에서도 클라이언트는 할 일이 남아있다면 메시지를 보낼 수 있다. No 60 패킷은 클라이언트도 TCP요청을 종료하고자 네이버 서버에게 보낸 패킷이며, 이 패킷을 받는 시점이 네이버 서버입장에서는 TCP연결 종료가 확실해지는 시점이다. 그리고 no 61 패킷에서 보여지듯이 네이버 서버는 FIN 플래그에 대응되는 ACK 플래그가 set된 패킷(대응되는 ACK번호를 포함)을 보내며, 이 패킷을 받는 시점이 클라이언트 입장에서는 TCP연결 종료가 확실해 지는 시점이다. 이 패킷이 상대방 서버로 전달되야 상대방 서버에서 TCP연결을 확실하게 종료할 수 있다. 위 과정에서 no 58은 순서번호 462와 ACK번호 655를 보냈고 이에 대한 응답으로 no 59에서 순서번호 655와 ACK번호 463을 보냈다. 이는 세그먼트 전송 과정에서 전송되는 바이트 수를 기준으로 654까지는 잘 받았다고 해석할 수 있다.
- application data를 포함한 TCP segment의 header 분석
[사진10]은 위의 TCP connection을 종료하는 단계에서 설명한 것과 같은 패킷 캡처이다. 위에서 말했듯이, No 51 ~ no 53은 3-way handshaking을 이용한 TCP 세션 확립을, no 58 ~ no 61은 4-way handshaking을 이용한 TCP 세션 종료과정을 보여준다. No 54은 TCP connection이 성립한 후, 클라이언트의 어플리케이션에서 데이터를 본격적으로 보내고 있음을 보여준다.
[사진11]은 no 54패킷(본격적으로 애플리케이션 데이터가 보내지는 시점)의 TCP header부분을 캡처했다. TCP연결이 성립한 후 클라이언트는 상대적인 순서번호 1과 ACK번호 1을 보내면서 시작하고 있다. TCP 헤더 길이는 20byte이며, 클라이언트는 자신의 window size가 1024 byte라고 알리고 있다. checksum도 보내고 있다. 이는 sender와 receiver에서 같은 알고리즘으로 계산되어 오류여부를 판단하는데 이용된다. urgent pointer는 필드가 유효한지 나타내며 긴급 데이터를 전송하기 위해 사용된다. PSH(push) 플래그가 SET되어 있는데, 이 패킷을 받은 receiver는 추가 데이터가 버퍼에 들어갈 때까지 기다리지 않고 즉시 데이터를 애플리케이션으로 내보낸다. 페이로드(애플리케이션 데이터)가 654byte 포함되어 있다. no 55 패킷은 no 54패킷을 잘 받았다는 TCP차원에서 보낸 패킷이다.
[사진12]는 네이버 서버에서 애플리케이션 계층부터 시작하여 생성된 패킷이다. 즉, no 54에서 애플리케이션이 요청한 데이터를 포함한다. 가장 마지막 라인을 보면 no 56과 57은 클라이언트로 오는 링크상의 MTU에 따른 fragmentation이 발생하였고 결국 no 56과 57은 원래 같은 패킷이었으며 클라이언트에 도착하여 reassemble되었음을 알 수 있다. No 54에서 654byte를 보냈고, 위 패킷의 ACK번호는 1+654인 655가 된다.
[사진13]은 follow stream을 보여준다. 위에서부터 3개는 TCP connection을 확립하는 과정이며, connection이 확실해진 후 애플리케이션 데이터를 포함한 패킷들이 오고 가기 시작한다. 중간에 서버에서 패킷을 쪼개어 보낸 것도 확인할 수 있었으며, 4-way handshaking을 하면서 TCP 연결을 종료하고 있다.
3) TCP 분석 심화
wireshark에서 tcp.analysis.retransmission로 필터링하여 retransmission이 발생한 패킷을 확인할 수 있었다. 확인 결과, wireshark는 총 3가지 종류의 retransmission으로 분류하였다.(TCP가 이 3가지로 분류하는 것은 아님)
- TCP Superious Retransmission
‘sender가 보낸 패킷이 receiver에게 도착했지만’ receiver로부터 ACK을 timeout내에 받지 못한 premature timeout과 같은 경우이다.
위 사진은 네이버에 접속하였을 때의 결과이다. [사진14]는 재전송의 원인이 된 패킷이며, [사진15]는 이에 대한 재전송 패킷이다. 두 패킷 모두 같은 source/destination port, sequence number, acknowledge number를 갖는다는 것을 알 수 있다.
- TCP Fast Retransmission
TCP receiver는 패킷 loss와 패킷 순서가 뒤바뀌어 오는 out-of-order를 알지 못한다. 따라서 예상하고 있는 순서번호 보다 나중의 순서번호를 갖는 패킷이 오면, “패킷 loss로 판단”하고 중복된 ACK을 보낼 수 있다.
[사진16]은 유튜브를 보면서 패킷을 캡처한 일부이며 172.217.175.78은 구글서버이다. 클라이언트는 중복적으로 같은 ACK을 3개 이상 보내고, 이에 대한 응답으로 서버는 순서번호가 3793인 패킷을 재전송하는 과정을 보여준다. Fast Retransmission의 경우 빠르게 3개이상의 중복된 ACK을 받으면 timeout이 발생하지 않더라도(timeout 내에) 재전송을 하는 방식이다. TCP가 Fast Retransmission을 제공하는 이유는 timeout기간이 상대적으로 길기 때문이다. 만약 TCP가 Fast Retransmission을 제공하지 않는다면 패킷 loss가 발생하더라도 상대적으로 긴 timeout을 기다리고 나서야 비로소 대응을 할 수 있다. 만약 이 긴 시간을 기다리며 RTT를 측정하면 RTT 신뢰도는 떨어진다.
- TCP Retransmission
[사진17]은 청와대(119.207.67.230) 홈페이지에서 여러 컨텐츠를 보았을 때 결과이다. 클라이언트(192.168.0.10)가 중복된 ACK넘버를 갖는 패킷을 여러 개 보내면서, 서버에게 순서번호 1328491(상대 값) 패킷을 계속 요청하는 것을 보아, 아마도 서버는 클라이언트에게 순서번호 1328491패킷을 보냈지만 loss가 발생한 것으로 보인다. 이에 대해 [사진17]의 마지막 두 개의 패킷을 서버가 재전송하고 있음을 알 수 있다.
위 3가지가 wireshark에서 분류하는 retransmission이다. Wireshark에서 분류하는 Retransmissio와 Superious Retransmission는 패킷 loss등으로 인한 timeout과 연관된 것이며, Fast Retransmission은 timeout이 충분히 길고, timeout이 발생하기 전에 중복된 3개 이상의 ACK을 보내는 경우에 해당한다. Timeout의 원인이 되는 retransmission의 문제점은 timeout의 주기가 비교적 길다는 것이다. 중복ACK을 발생시키지 않고 Timeout이 길다면 잃어버린 패킷을 다시 보내기 전에 상대를 오랫동안 기다리게 한다는 점에서 지연을 증가시킨다.
TCP receiver는 패킷 loss또는 out-of-order로 인하여 예상했던 순서번호와 다른 순서번호의 패킷이 올 때, 마지막으로 정상적인 순서번호를 갖는 패킷에 대한 ACK을 중복적으로 보낸다. 이때 timeout전에 3개이상의 중복된 ACK을 갖는 패킷이 보내진다면 이를 수신한 쪽에서는 timer가 expire되기 전에 잃어버린 패킷을 빠르게 재전송한다.
다음 사진은 네이버의 뉴스를 하나 시청하였을 때, 시간에 따른 필자의 클라이언트로 도착한 패킷의 순서번호를 보여준다. 192.168.0.10은 필자의 노트북이며 1.248.254.31은 iplocation.net에 검색해본 결과 ISP가 SK Broadband이고 지리적 위치가 서울시임을 알 수 있었다.
x축은 시간이고 y축은 실제 순서번호를 보여주는데, 시간이 2초 주변 부분에 순서번호가 급격히 떨어졌음을 알 수 있다. 이를 좀 더 확대하면 다음과 같다.
[사진19]의 1번 구간과 2번 구간을 비교해 보면, 1번 구간은 시간상으로 2번보다 이전에 클라이언트가 받은 패킷인데, 이는 2번 구간의 패킷보다 큰 순서번호를 갖고 있다. 따라서 2번 구간의 패킷들은 Retransmission된 패킷을 의미한다. 여기서 알 수 있는 또 다른 점은 TCP는 GBN방식이 아니라는 것이다. GBN방식이라면 재전송이 될 패킷과 그보다 큰 순서번호를 갖는 패킷들이 모두 재전송되어야 할 텐데, [사진19]에서 보여주는 그래프를 보면 TCP는 기껏해야 세그먼트 한 두개 만을 재전송하고 있다.
4. 새로 알게 된 지식
1) TCP Reset (RST flag)
TCP Reset은 다양한 원인에 의해 나타나는데, TCP Reset이 있다고 해서 무조건 문제 상황이 발생했다고 해석하면 안된다. 예를 들어, 불필요하게 주기적으로 자주 connection이 open된다면 reset을 통해 connection을 종료할 수 있다. Connection을 종료할 때, 먼저 TCP 연결 종료를 요청한 곳에서 최종적으로 TIMED_WAIT가 남게 되며, 이는 2 x Maximum Segment Lifetime에 해당한다. TIMED_WAIT는 마지막 ACK이 제대로 도착해야 상대방이 확실히 연결이 끝났음을 알 수 있으므로 필요하지만, TIMED_WAIT상태를 유지하지 않기를 원한다면(새로운 개체와 빠른 TCP연결) connection을 reset할 수 있다.
[사진20]은 통계청 홈페이지에 접속하고 창을 닫았을 때의 결과이다. 125.60.43.187은 통계청의 웹서버 주소이다. 해당 패킷 캡쳐 파일에는 4-way handshaking을 통한 connection 종료 과정은 없었으며 클라이언트가 일방적으로 connection 종료를 했음을 알 수 있다. reset을 통해 이전 connection에 할당되었던 자원을 해제하고 시스템을 사용가능 하게 만들며 TIMED_WAIT만큼의 시간이 필요하지 않게 된다.
2) TCP push (PSH flag)
PSH플래그는 receiver의 TCP buffer의 패킷을 빠르게 애플리케이션 계층으로 전송하기 위해 사용된다고 알고 있었지만, PSH의 용도 중에 하나를 알게 되었다. 다음 사진은 네이버에 접속하였을 때의 TCP 연결과 즉시 데이터 요청과 응답을 보여준다.
[사진21]의 no 56패킷에는 PSH 플래그가 set되어있으며, 클라이언트에서 no 57패킷과 reassemble되는데 no 57패킷은 no 54에서 클라이언트가 요청한 데이터를 포함한다. 또한 no 57이후로는 네이버 초기 창을 띄우는데 더 이상의 데이터 교환은 없다. 여기서 알 수 있는 점은 PSH 플래그가 설정된 패킷을 네이버 서버가 보냄으로써 클라이언트에 추가할 데이터가 더 이상 없고 응답 데이터가 애플리케이션으로 즉시 전송되어야 함(빠르게 네이버 창의 content를 띄움)을 알 수 있다. 즉, no 56패킷은 애플리케이션 데이터를 포함하는 no 57패킷과 reassemble되므로 이전에 서버가 보냈던 애플리케이션 데이터부터 no 57이 포함하는 애플리케이션 데이터까지(사실 이전에 보낸 데이터는 없음) 클라이언트의 버퍼에서 빠르게 애플리케이션으로 넘기라는 의미이다, 이는 네이버 접속 창을 구성하기위한 content를 모두 보냈음을 의미한다.
3) TLS
패킷 캡처 도중에 TLS라는 프로토콜을 확인할 수 있었다. TLS(Transport Layer Security)는 통신 내용(특히 애플리케이션 데이터)을 암호화해주는 암호규약이다. 이는 TCP를 사용할 때에도 적용되며 단말 간에 보안과 무결성(사용자 데이터 변경, 메모리의 변경, 전송 중 메시지 변경, 도청 등의 위협에 인한 안전성)을 확보해 준다. 예를 들어, https를 사용하면 애플리케이션 데이터(HTML 파일 등)는 sender에서 TLS에 의해 암호화되고, TCP단계로 넘겨지며 receiver에 도착할 때까지 암호화된 상태로 전송된다. receiver에서 이를 복호화하여 원래 데이터를 사용자에게 제공한다. https외에도 SMTP, POP 등의 프로토콜도 TLS를 이용한다.
[사진23]은 유튜브를 시청했을 때의 패킷 캡처 일부분이며, 172.217.175.78은 구글이다. 구글서버에서 TLS v1.3 프로토콜을 이용하여 애플리케이션 데이터를 안전하게 보내고 있음을 알 수 있다. 또한 이 경우 애플리케이션 데이터는 암호화되었으므로 애플리케이션 데이터에 대한 정보는 확인할 수 없었다.
[사진24]를 보면 source, destination의 IP주소, port번호는 보여진다. 그리고 http-over-tls를 보고 유튜브는 https로 애플리케이션 데이터를 보냈음을 알 수 있다. 또한 애플리케이션 데이터의 길이와, 암호화된 애플리케이션 데이터도 볼 수 있었다. 따라서 TLS를 사용하더라도 연결의 종단점, 암호화 타입, 전송된 데이터의 빈도([사진23]을 보면 알 수 있음), 전송된 데이터의 양은 암호화되지 않고, 단지 애플리케이션 데이터를 암호화하여 receiver외에는 읽거나 수정할 수 없음을 알 수 있었다.
[사진26]은 카카오톡 PC버전으로 친구에게 “안녕”이라는 메시지를 보냈을 때의 패킷이며 [사진25]의 no 881패킷이다. www.iplocation.net에서 211.231.100.211은 카카오톡의 IP주소임을 알았고 마지막 줄의 Encrypted Application Data(암호화된 데이터)를 복호화하면 “안녕”이 나오지 않을까 추측했다. 또한 no 881의 ACK번호와 no 884의 순서번호가 같은 것으로 보아, “안녕”이라는 메시지를 잘 받았다는 응답으로 해석할 수 있었다. 따라서 카카오톡의 메시지는 TLS 프로토콜에 의해 암호화되어 전송중인 메시지를 다른 사람이 보거나 수정할 수 없도록 함을 알 수 있었다.
4) 간추려진 TCP connection 종료
[사진27]은 위의 [사진25]와 [사진26]과 같은 패킷 캡처 파일이며 카카오톡PC버전에서 로그아웃 했을 때의 결과이다. 4-way handshaking과 비교하면, [사진27]은 첫 번째 FIN 플래그(먼저 연결 종료를 신청한 클라이언트 쪽에서 보낸)에 대한 응답인 ACK 플래그 패킷이 빠저있다. 하지만 카카오톡이 보낸 no 895패킷을 보면 ACK번호로 연결종료를 요청한 패킷을 받았으며 FIN 플래그를 set함으로써 연결종료를 서로 요청했음을 알 수 있다. 마지막으로 클라이언트는 no 896 패킷을 보냄으로써 카카오톡이 보낸 FIN플래크 패킷을 받았음을 확인한다. 따라서 3개의 패킷으로도 보다 빠르게 TCP 세션을 종료할 수 있음을 알 수 있었다.
'[ Basic ] > # 네트워크' 카테고리의 다른 글
| SSL/TLS, HTTPS 기초 개념 (0) | 2023.05.03 |
|---|---|
| [Network] Forward Proxy, Reverse Proxy (0) | 2022.09.22 |
| <추천티비>OSI 7계층을 기반으로 네트워크 흐름 이해하기 (0) | 2022.04.17 |
| [WEB] CORS(Cross-Origin Resource Sharing) (0) | 2021.12.05 |
| [HTTP] HTTP 프로토콜 패킷 분석 (0) | 2021.08.04 |