3.9인터넷
인터넷의 구성요소들과 작동 원리
TL;DR
추억의 쪽지 시험
63. 표준과 프로토콜의 세계, 인터넷
앞선 포스팅에선 이더넷과 무선 네트워크 같은 로컬 네트워크 기술을 살펴보았다. 전화 시스템은 전 세계의 전화기를 연결한다. 그럼, 전 세계의 컴퓨터를 연결하려면 어떻게 해야할까?
이 질문에 대한 답으로 나온 것이 인터넷이다. 인터넷은 거대한 네트워크도 거대한 컴퓨터도 아니다. 인터넷은 느슨하고 체계가 없고 혼란스럽고 임시적인 네트워크의 모음으로, 네트워크와 그 위에 있는 컴퓨터가 서로 통신하는 방법을 규정하는 표준으로 묶여 있다.
물리적 특성이 서로 다르고(광섬유, 이더넷, 무선 등) 서로 멀리 떨어져 있는 네트워크들을 연결하기 위해선 네트워크와 컴퓨터를 식별할 이름과 주소가 필요하다. 또, 직접 연결되지 않은 네트워크 사이의 경로를 찾을 수 있어야 한다. 그리고 정보가 이동함에 따라 그 형식을 어떻게 바꿀 것인지, 오류, 지연, 과부하에 어떻게 대처할 것인지에 대한 합의도 필요하다.
모든 네트워크(특히 인터넷)에서, 오는 데이터를 어떤 형식으로 구성할지, 누가 먼저 말하고 어떤 응답이 이어질 수 있는지, 오류를 어떻게 처리할지 등에 대한 합의를 프로토콜(protocol)이라고 한다. 즉, 프로토콜은 상대방과 소통하기 위한 일련의 규칙이다.
프로토콜과 표준에 합의하는 일은 복잡한데, 많은 기득권 세력(장비 판매 업체, 특허나 영업 비밀을 보유한 단체, 각국 정부 등)이 존재하기 때문이다.
64. 인터넷이 가능한 메커니즘
인터넷은 1960년대에 지리적으로 멀리 떨어진 위치에 있는 컴퓨터를 연결하려는 네트워크를 구축하려는 시도에서 시작되었다. 프로젝트 자금의 대부분이 미국 국방성 고등연구계획국(Advanced Research Projects Agency, ARPA)에서 지원받았기 때문에 이 네트워크는 ARPANET이라고 불렸다. 첫번재 아파넷 메시지는 1969년 10월 29일에 UCLA에 있는 컴퓨터에서 약 550km 떨어진 스탠퍼드 연구소에 있는 컴퓨터로 전송되었기 때문에, 이 날이 인터넷이 탄생한 날이라고 할 수 있다.
참고로 이 때 메시지는 LOGIN이라고 보내려고 했지만, 시스템 충돌로 LO 까지만 갔다.
아파넷은 대학교 컴퓨터과학부와 연구 기관을 연결할 목적이었지만, 컴퓨터와 기술은 시간이 지나며 더 새로운 컴퓨터와 기술들로 교체되었고, 1990년대에 상업적인 영역으로 퍼져나갔고 언젠가부터 인터넷이라고 불리게 되었다.
오늘날 인터넷은 느슨하게 연결된 수백만 개의 독립적인 네트워크로 구성된다. 가까이 있는 컴퓨터끼리는 근거리 통신망으로 연결되는데, 주로 무선 이더넷이다. 다음으로 이 근거리 네트워크들이 게이트웨이(Gateway) 또는 라우터(router)를 통해 다른 네트워크로 연결된다. 게이트웨이와 라우터는 한 네트워크에서 다음 네트워크로 정보 패킷을 라우팅하는데 전문화된 컴퓨터를 말한다. 게이트웨이는 라우팅 정보를 서로 교환하여 어떤 개체들이 연결되어 있고 접근 가능한지 파악한다.
라우터와 게이트웨이의 역할과 기능은 서로 다르다. 라우터는 여러 네트워크 간의 데이터 패킷을 전송하는 장치로, 데이터가 목적지까지 가장 효율적인 경로를 통해 도달할 수 있게 한다(라우팅). 즉, 경로를 결정하고 트래픽을 관리하며, 네트워크 간 연결을 하고 이 과정의 보안 기능을 수행한다.
반면, 게이트웨이는 서로 다른 네트워크 프로토콜을 사용하는 두 네트워크를 이어주는 장치 또는 소프트웨어이다. 예를 들어, 인터넷 게이트웨이는 가정이나 기업의 네트워크를 인터넷과 연결한다. 이메일 게이트웨이는 이메일 서버와 외부 이메일 시스템 간 통신을 관리한다.
각 네트워크는 집, 사무실, 기숙사에 있는 컴퓨터나 전화 등 여러 호스트 시스템을 연결할 수 있다. 가정 내 개별 컴퓨터는 주로 무선 통신으로 라우터에 연결되고, 라우터는 케이블이나 DSL로 ISP(Internet Service Provider, 인터넷 서비스 제공 업체)에 연결된다.
인터넷에서 데이터는 IP 패킷(IP Packet)으로 전달된다. IP는 Internet Protocol의 약자로, 이후 보다 자세히 살펴보겠지만 인터넷 상에서 데이터를 패킷으로 전달할 때 각 패킷이 올바른 목적지에 도달할 수 있도록 주소를 부여하고 경로를 결정하는 규칙을 정의한 프로토콜이다. IP 패킷은 여러 개의 작은 이더넷 패킷으로 분할되는데, 최대 크기의 이더넷 패킷(약 1,500바이트)이 최대 크기의 IP 패킷(약 65,000바이트)보다 훨씬 작기 때문이다.
각 IP 패킷은 여러 개의 게이트웨이를 통과해서 목적지로 간다. 통과하는 게이트웨이들은 여러 회사들과 기관들이 각기 소유하고 운영하고 있어, 서로 다른 국가에 있을 확률이 높다. 트래픽은 최단 경로를 따르지 않고, 편의성과 비용 때문에 더 긴 경로로 라우팅하기도 한다.
이런 데이터 전달 시스템이 작동하기 위해선 몇 가지 메커니즘이 필요하다. 첫째는 주소이다. 각 호스트 컴퓨터(인터넷에 연결되어 데이터를 송수신할 수 있는 개별 장치)에는 전화번호처럼 인터넷 상의 모든 호스트 중에서 자신을 고유하게 식별할 주소가 있어야 한다. 이 식별 주소를 IP 주소(IP address)라고 하는데, 짧은 주소는 인터넷 프로토콜 버전(IPv4)이고, 긴 주소는 버전6(IPv6)이다.
IPv4 주소는 4개의 바이트를 쓰는데, 각 바이트를 십진수로 나타내고 마침표로 구분해서 표기한다. 예를 들면 구글 도메인(google.com)의 IP 주소는 142.251.35.174인데, 각각 0부터 255(1바이트는 8비트, 255는 2^8-1이다) 사이의 값인 142, 251, 35, 174를 연결한 것이다. 이와 구분하기 위해 IPv6주소는 16개의 십육진수 바이트를 두 개씩 콜론으로 구분해서 작성한다.
IP주소는 겹치면 안되므로, 전 세계의 IP 주소를 관리하는 기관이 필요하다. 해당 기관인 IANA(Internet Assigned Numbers Authority)는 연속적인 IP 주소 블록을 각 국가나 인터넷 서비스 제공자(ISP)와 같은 네트워크 관리자에게 할당한다. 네트워크 관리자들은 각각 할당된 블록 내에서 자신의 네트워크에 연결된 각 장치(호스트 컴퓨터)들에 개별 주소를 배분한다. 따라서 각 호스트 컴퓨터는 자신이 속한 네트워크에 따라 로컬로 할당된 고유 주소를 갖는다.
이 고유한 주소는 데스크톱 컴퓨터에서는 영구적이지만, 모바일 장치에서는 동적이며 장치가 인터넷에 다시 연결될 때마다 바뀐다. 이를 DHCP(Dynamic Host Configuration Protocol)이라고 하는데, 인터넷에 연결할 때마다 IP 주소가 바뀐다는 의미이다. 데스크톱이 고정적인 IP 주소를 쓰는 이유는, 보통 데스크톱이 집이나 회사에서 고정된 위치에 사용되고 파일 서버, 프린터 공유 등의 기능을 쓸 때 고정 IP가 더 편리하기 때문이다. 또, 보통 장시간 켜져 있으므로 IP를 바꿀 이유가 적다. 반면 모바일 장치는 자주 이동하며 네트워크가 와이파이 -> 5G -> 다른 와이파이 등으로 바뀌면서 IP 주소가 변경되어야 한다. 이런 경우는 고정 IP를 부여하면 IP 자원 낭비가 심해지기에 DHCP로 IP를 변경한다.
다음으로 필요한 메커니즘은 이름(name)이다. 사람들이 직접 접근하려고 시도하는 호스트는 IP 주소처럼 임의의 32비트 숫자여서는 접근할 수 없다. 따라서 도메인 네임(Domain Name)이라고 부르는, www.sungyup.com과 같은 이름이 필요하고, IP 주소와 이 이름을 서로 변환해주는 시스템인 DNS(Domane Name System)이 필요하다.
또, 라우팅(routing), 즉 패킷이 출발지에서 목적지까지의 경로를 찾는 메커니즘이 필요하다. 이 일은 게이트웨이가 수행한다. 게이트웨이는 어떤 개체가 어디에 연결되어 있는지 자기들끼리 라우팅 정보를 끊임없이 교환하고, 그 정보를 이용해 각 수신 패킷을 최종 목적지에 더 가까운 게이트웨이 쪽으로 계속 전달한다.
마지막으로, 프로토콜(protocol)이라는, 정보가 한 컴퓨터에서 다른 컴퓨터로 성공적으로 복사되도록 앞서 말한 모든 요소들이 어떻게 상호 운용되는지 정확하고 상세하게 설명하는 규칙과 절차가 필요하다. IP는 그 중 핵심 프로토콜로, 전송 중인 정보에 대해 균일한 전송 메커니즘과 공통 형식을 정의한다. IP 패킷은 자체 프로토콜을 사용하는 다양한 종류의 네트워크 하드웨어에 의해 전달된다.
IP 바로 위에서는 TCP(Transmission Control Protocol, 전송 제어 프로토콜)라는 프로토콜이 IP를 사용해 출발지부터 목적지까지 임의 길이 바이트 시퀀스를 전송하기 위한 안정적인 메커니즘을 제공한다. 또, TCP 위에서는 그 위의 프로토콜들이 TCP를 사용해 웹 브라우징, 메일, 파일 공유 등 우리가 흔히 말하는 인터넷에 해당하는 서비스를 제공한다. 이외에도 여러 프로토콜들이 합쳐져 인터넷을 구성한다. 예를 들면, 앞서 언급한 DHCP도 프로토콜이다.
65. 나만의 도메인이 갖고 싶다면?
인터넷의 핵심 기술 대부분은 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)라는 이름의 단체에 의해 개발되었다. 이 단체는 인터넷 기술의 작동 방식을 설계하고 기술 표준 문서를 만든다. 기술적인 사양은 정기적 회의 및 자주 발표되는 RFC(Requests for Comments)라는 문서로 논의되고, 여러 번의 수정을 걸쳐 결국 표준이 된다.
인터넷의 다른 부분인 도메인 네임, IP 주소, 일부 프로토콜 정보처럼 인터넷이 제대로 작동하려면 고유하게 유지돼야 하는 이름과 번호를 할당하는 단체는 ICANN(Internet Corporation for Assigned Names and Numbers)이다. ICANN은 도메인 네임 등록 대행 업체에 권한을 승인하고, 등록 대행 업체는 개인이나 단체에 도메인 네임을 할당한다.
ICANN은 원래는 미국 상무부 기관이었으나 현재는 캘리포니아에 위치한 비영리 조직이며, 등록 대행 업체와 도메인 네임 등록에서 얻는 수수료로 대부분의 자금을 조달하고 있다. 이 역사적/위치적 문제 때문에 ICANN은 정치적 문제들과도 엮인다. 예를 들면, 2020년에 Ethos Capital이라는 정체불명의 사모투자 회사가 .org 레지스트리를 인수하려고 입찰했고, ICANN은 동의했다. 하지만 이들의 인수 목적이 레지스트리 통제권을 확보한 후에 고객 데이터를 판매해 가격을 높이는 것이라는 사실이 드러나, 캘리포니아주 법무장관이 나서서 조치를 취했다.
도메인 네임 시스템(DNS)
.com
, .edu
와 같은 이름이나, .us
, .kr
과 같은 국가 코드를 최상위 도메인(TLD, top-level domain)이라고 한다. 최상위 도메인은 하위 도메인에 관리 책임과 이름을 정의할 책임을 위임한다. 예를 들어, 프린스턴 대학은 princeton.edu를 관리할 책임을 지고 해당 범위 내의 서브도메인 네임을 정의한다. 고전학과는 classics.princeton.edu, 컴퓨터학과는 cs.princeton.edu 같은 식이다.
도메인 이름은 지리적인 의미를 담고 있지 않다. 단일 컴퓨터가 여러 도메인에 서비스를 제공할 수 있는가(예를 들면, 호스팅 서비스 회사) 하면, 많은 컴퓨터가 단일 도메인에 서비스를 제공(예를 들면, 페이스북이나 아마존 등 대형 사이트)하기도 한다. 어떤 국가 코드는 특정 사업군과 잘 맞아 해당 국가와 관련 없는 사업체들이 쓰기도 한다. 예를 들면 .tv
를 가진 투발루, .md
(medical doctor)를 가진 몰도바 등이다.
IP 주소
각 네트워크와 거기에 연결된 각각의 호스트 컴퓨터는 다른 장치와 통신할 수 있도록 IP 주소가 있어야 한다. 이 주소는 특정 시점에서 한 호스트만 해당 값을 사용할 수 있어야하는 고유 주소이다.
IP 주소는 ICANN이 블록 단위로 할당하며, 그 블록은 해당 블록을 받은 기관이 나눠서 할당한다. 예를 들어, 프린스턴 대학은 128.112.ddd.ddd와 140.180.ddd.ddd라는 두개의 블록이 있다. 여기서 ddd는 0 ~ 255(2^8 - 1)사이의 십진수다. 각 블록 당 ddd가 2개이니 각각 65,536(2^16)개 호스트가 가능하고, 합치면 약 131,000개의 호스트를 쓸 수 있다.
도메인 네임만큼이나 IP 주소 블록에도 수치적 의미나 지리적 의미가 없다. 즉, IP 주소 블록이 인접해 있다고 물리적으로 가까운 컴퓨터가 아니다. IP 주소만으로는 지리적 위치를 유추할 방법이 없다. 다만, DNS는 역방향 조회(IP 주소를 이용해 도메인 네임을 알아내는 기능)를 지원하기 때문에 이를 통해 도메인 네임을 알아내 위치를 추측할 수 있다. 물론 이 경우에도 서버는 완전히 다른데 있을 수 있다.
IPv4는 최대 2^32개, 즉 약 43억 개의 주소만 지원 가능하다. 스마트폰, IoT 기기 등의 폭발적인 증가로 인해 이 수는 적을 뿐 아니라, IP 주소가 블록 단위로 할당되기에 효율적이지도 않은 방식이다.(예를 들면, 프린스턴 대학교에서 동시에 131,000개의 컴퓨터가 사용 중인 경우는 없을 것이다)
여러 개의 호스트를 단일 IP 주소에 편승하게 하는 기법을 사용하면 이 문제를 다소 완화할 수 있다. 가정용 무선 공유기는 일반적으로 NAT(Network Address Translation, 네트워크 주소 변환)이라는 기술을 사용한다. 이 기술은 단일 외부 IP 주소로 여러 내부 IP 주소에 서비스를 제공할 수 있게 한다. NAT이 지원되면, 모든 가정용 장치는 외부에서 볼 때 같은 IP 주소를 갖는 것처럼 보이며, 장치 내부의 하드웨어와 소프트웨어가 변환을 처리한다.
물론 가장 직접적인 해결 방법은 주소를 늘리는 것이다. IPv6은 2^128, 즉 약 3*10^38개의 주소가 있으므로 현재로썬 꽤 넉넉한 주소를 지원할 수 있다.
그런데 여기서, 왜 IPv4 다음이 IPv6일까? 사실 IPv5도 있었다! 하지만 IPv5는 음성 통신, 비디오 스트리밍 등 실시간 데이터 전송을 위한 실험적 프로토콜이었고 IPv4의 주소 공간 문제를 해결하지 못해서 실험 단계에서 종료되고, IPv5는 건너뛰고 IPv6이 차세대 프로토콜로 정식 채택되었다.
루트 서버
DNS는 도메인 네임을 IP 주소로 변환하는 시스템이다. 이를 위해선 모든 최상위 도메인들의 IP 주소들을 알고 있는 서버인 Root Name Server(루트 네임 서버)가 필요하다.
예를 들어, www.cs.mit.edu라는 도메인의 IP 주소를 확인하려면 먼저 루트 서버에 .edu라는 최상위 도메인의 네임 서버 위치를 물어본다. 이후 .edu 네임 서버에 mit.edu를 물어봐 MIT에 도달하고, 다시 MIT 네임 서버에 cs.mit.edu를, 마지막으로 www.cs.mit.edu에 대해 알고 있는 네임 서버에 도달하여 IP 주소를 확인한다.
DNS는 검색의 효율화를 위해 트리 구조 기반의 탐색 알고리즘을 사용한다. 최상위 단계에서 실행한 첫 쿼리를 통해 대부분의 불필요한 경로를 걸러내며, 이 패턴이 트리를 내려갈 때마다 반복된다. 또, 네임 서버는 캐싱을 통해 최근에 조회되어 자신을 거쳐 간 이름과 주소를 일정 시간 동안 저장한다. 그리고 이 이름과 주소에 대한 요청을 또 받으면 멀리서 찾지 않고 로컬 정보로 응답한다. 즉, 특정 사이트에 처음 접근하면, 최근에 이 사이트를 조회한 사람이 없어서 로컬 네임 서버가 루트 서버에 IP 주소를 물어보고 쿼리를 늦게 반환하겠지만, 곧 다시 접근 요청을 하면 캐시된 정보를 불러와 웹사이트가 더 빨리 실행된다.
루트 서버는 전 세계에 13개가 분포되어 있고, 각 루트 서버는 서로 멀리 떨어져 있는 여러 대의 컴퓨터(루트 서버 인스턴스)들로 구성된다. 이렇게 여러 인스턴스로 분산함으로 루트 서버는 부하가 분산되고 속도가 향상된다. 여기에는 애니캐스트(Anycast)라는 기술이 사용되는데, 동일한 IP를 가진 서버를 전 세계에 배치함으로, DNS 요청이 가장 가까운 서버로 라우팅되어 응답받을 수 있도록 한다.
자신만의 도메인 등록하기
도메인을 등록하려면 ICANN이 전 세계적으로 인가한 수백 개의 등록 대행 업체 중 하나를 선택하고, 도메인 네임을 고른 다음 비용을 매년 지불하면 된다.
도메인 네임은 63자로 제한되고 일반적으로는 영문자, 숫자, 하이픈만 포함할 수 있지만, 유니코드 문자를 사용할 수도 있다. 아스키코드 외의 문자가 있다면 퓨니코드(Punycode)라는 표준 인코딩 방식이 유니코드 문자열을 적절한 영문자-숫자-하이픈 조합으로 변환한다.
도메인을 등록했다면 사이트를 관리할 호스트(host)가 필요하다. 호스트는 사이트가 방문자에게 표시할 콘텐츠를 보유하고 제공하는 컴퓨터이다. 또, 네임 서버(name server)가 있어야 어딘가에 있는 누군가가 우리가 등록한 도메인의 IP 주소를 찾으려고 할 때 호스트의 IP 주소로 응답할 수 있다. 네임 서버는 보통 등록 대행 업체가 서비스를 제공한다.
66. 출발지에서 목적지까지, 인터넷 경로 확인하기
출발지에서 목적지까지 경로를 찾는 라우팅(Routing)은 모든 대규모 네트워크의 핵심적인 문제다. 규모가 작은 정적 네트워크의 경우 모든 가능한 목적지에 대해 경로상의 다음 단계를 제공할 수 있다. 하지만 이런 정적 테이블을 쓰기에 인터넷은 너무나도 크고 동적으로 변하기까지 한다. 그래서 인터넷 게이트웨이는 인접한 게이트웨이와 정보를 교환하여 라우팅 정보를 끊임없이 새로 고친다.
인터넷의 규모가 워낙 크기 때문에 복잡한 라우팅 정보를 관리하기 위해선 계층적 구조가 필요하다. 최상위 레벨에서는 수만 개의 자율 시스템(autonomous system)이 있는데, 이들은 자신이 포함하는 네트워크 라우팅 정보를 제공한다. 일반적으로 자율 시스템은 대형 ISP(한국에선 KT 인터넷, SK 브로드밴드, LG 유플러스 등)에 해당한다. 자율 시스템은 내부 라우팅 정보는 로컬로 교환하고, 외부 자율 시스템에는 통합된 라우팅 정보를 제공한다.
ISP는 게이트웨이를 통해 서로 연결된다. 주요 통신 사업자 간 대용량 트래픽의 경우, 여러 회사의 네트워크 연결이 만나서 네트워크 간 물리적 연결이 이루어지는 IXP(Internet eXchange Point)를 이용한다. IXP는 한 네트워크의 데이터가 다른 네트워크로 효율적으로 전달되게 한다. 세계에서 가장 큰 IXP에 속하는 DE-CIX 프랑크푸르트 IXP는 평균 6테라비트/초의 트래픽을 처리한다.
몇몇 국가는 국내에서 국외로, 또는 국외에서 국내로 접근을 제공하는 게이트웨이를 비교적 적게 두어 정부가 트래픽을 감시하고 필터링하기 쉽게 한다.
라우팅 정보를 탐색해보면 미국이 주로 포함된 수많은 나라의 게이트웨이를 통과하는 경우가 많다. 아래는 해저 케이블 지도로, 광케이블이 해저로 어떻게 연결되어 있는지를 볼 수 있다.(지상 케이블은 표시되어 있지 않은 지도이다)

67. 데이터를 전송하는 핵심 프로토콜 TCP/IP
네트워크 프로토콜은 양측이 상호작용하는 방식에 관한 규칙을 정의한다. 인터넷의 많은 프로토콜들 중 가장 핵심적인 두 가지는 IP와 TCP이다. IP(Internet Protocol)는 개별 패킷의 형식을 지정하고 패킷을 전송하는 방법을 정의한다. 그리고, TCP(Transmission Control Protocol)는 IP 패킷을 데이터 스트림으로 결합하고 서비스에 연결하는 방법을 정의한다. 이 두 프로토콜을 합쳐서 TCP/IP라고 한다.
IP 레벨 위에서는 TCP가 안정적인 통신을 제공하므로 사용자(=프로그래머)는 패킷에 관해 생각할 필요가 없다. TCP 위에는 애플리케이션 레벨 프로토콜들이 있고, 애플리케이션 레벨 프로토콜은 웹, 메일, 파일 전송 등의 서비스를 제공한다. 여러 개의 프로토콜 계층은 각각 바로 아래의 프로토콜 서비스에 의존하고, 바로 위에 있는 프로토콜에 서비스를 제공한다.

UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)은 TCP와 같은 레벨의 또 다른 프로토콜이다. UDP는 TCP보다 훨씬 단순하고, 양방향 스트리밍이 필요하지 않은 데이터 교환에 사용된다. UDP는 다소 제한된 기능만 제공함으로써 패킷을 효율적으로 전송하는 용도로 활용된다. DNS가 UDP를 사용하고, 비디오 스트리밍, 일부 온라인 게임도 UDP를 쓴다.
IP: 인터넷 프로토콜
IP는 신뢰성 없는(unreliable) 비연결형(connectionless) 패킷 전송 서비스를 제공한다. 이 말은 얼핏보면 다소 당황스러울 수 있는데, 실제론 아래와 같은 의미이다.
- 신뢰성 없음: 데이터가 도착할지 보장하지 않는다.
- IP는 데이터를 전송만 해줄 뿐, 데이터가 제대로 도착했는지, 순서가 맞는지, 중간에 손실됐는지 확인하거나 보정하지 않는다.
- 이를 최선은 다했다는 의미로 '최선형(best effort)' 프로토콜이라고 한다.
- 비연결형 : 데이터를 목적지로 바로 보낸다.
- 데이터를 보내기 전에 연결을 맺는 등 준비과정 없이 그냥 바로 목적지로 전송한다.
- 각 IP 패킷이 다른 IP 패킷과 관계가 없다.
- 어떤 패킷이 다음 게이트웨이로 전달되고 나면 그 패킷에 대해 아무것도 기억하지 않는다.
IP 패킷의 최대 크기는 약 65KB이다. 따라서 긴 메시지인 경우 작은 덩어리들로 분할되어 따로따로 전송된 다음, 받는 쪽에서 재조합한다. IP 패킷은 이더넷 패킷처럼 형식이 정해져있다.

위의 IP 패킷에서 TTL은 Time to Live를 뜻하는데, TTL은 패킷의 출발지에서 초깃값(보통 40)으로 설정되고, 패킷을 처리하는 각 게이트웨이를 거칠 때마다 1씩 감소되는 1바이트 필드다. 이 카운트가 0까지 내려가면 패킷은 폐기되고 송신자에게 오류 패킷이 보내진다. 인터넷을 통한 일반적인 이동 경로에는 15~20개의 게이트웨이가 포함된다. 따라서, 어떤 패킷이 255개(1바이트 필드이니)의 홉을 쓴다면 뭔가 문제가 있는 것이며, 높은 확률로 순환 상태에 빠졌을 것이다. TTL 필드는 순환 문제를 해결해주는건 아니지만, 개별 패킷이 영원히 살아서 돌아다니는 문제는 확실히 방지해준다.
하지만 IP는 정보가 도착할 것이라는 약속은 하지 않는다. 이 신뢰성 없는 계층에서 신뢰성 있는 통신을 만드는 것이 TCP이다.
TCP: 전송 제어 프로토콜
TCP는 인터넷에서 가장 널리 사용되는 전송 계층 프로토콜 중 하나로, 사용자에게 신뢰성 있는 양방향 스트림을 제공한다. 즉, 데이터를 한쪽 끝에서 넣으면 반대쪽 끝에서 안정적으로, 순서에 맞게, 오류 없이 나올 수 있게 한다.
TCP는 세부사항이 많지만, 기본 아이디어는 간단하다. 데이터를 보내기 전에 연결을 먼저 맺고, 보낸 데이터가 정확하게 도착했는지 확인하며, 순서가 바뀌지 않도록 관리한다.
구체적으로 살펴보면 우선, 바이트 스트림이 여러 조각으로 나뉘어 세그먼트(segment)라고 하는 TCP 패킷에 담긴다. TCP 세그먼트에는 실제 데이터뿐 아니라 제어 정보를 포함하는 헤더들도 들어 있다. 제어 정보에는 수신자가 각 패킷이 스트림의 어느 부분인지를 알 수 있도록 하는 시퀀스 번호가 있다. 이 덕에 세그먼트가 분실되면 어느 세그먼트인지 알 수 있으며, 재전송한다. 또, 세그먼트에는 오류 검출 정보도 있어 손상된 세그먼트도 찾아낼 수 있다. 각 TCP 세그먼트는 IP 패킷에 실려 전송된다.

이렇게 IP 패킷에 실려온 각각의 TCP 세그먼트에 대해 수신자는 긍정 또는 부정으로 확인 응답을 보내야 한다. 만약 세그먼트를 받았다면 긍정 응답(acknowledgment)을 보내는데, 적절한 시간 간격 후에 긍정 응답을 받지 못한다면 발신자는 해당 세그먼트가 분실됐다고 추정하고 다시 보낸다. 반대로, 세그먼트를 기다리고 있는데 일정 시간 동안 못 받았다면 부정 응답(negative acknowledgment)을 수신자가 보내며, 발신자는 다시 세그먼트를 보내야 한다는 것을 알게 된다.
여기서 확인 응답 자체가 분실되면 상황이 복잡해지지만, TCP에는 무언가 잘못됐다고 간주하기까지 얼마나 기다릴지 결정하는 타이머가 여러개 있어서 어떤 작업이 너무 오래 걸리면 복구를 시도하고, 결국 연결이 시간 초과되면 중단된다.
TCP에는 이 절차가 효율적으로 작동하게 하는 메커니즘도 있다. 예를 들면, 발신자는 이전 패킷에 대한 확인 응답을 기다리지 않고도 패킷을 보낼 수 있고, 수신자는 여러 개의 패킷에 대한 확인 응답을 한번에 보낼 수 있다.
두 호스트 컴퓨터 간에 TCP 연결이 설정되면, 그 연결은 목적지 컴퓨터(서버)의 특정 포트와 연결된다. 예를 들면 웹 서버는 80번 포트를 사용하고, 메일 서버는 25번 포트를 사용한다. 브라우저가 구글 웹사이트에 접근하려면 구글의 80번 포트에 TCP 연결을 설정하지만, 메일 프로그램은 구글 메일 서버에 25번 포트를 사용해 접근한다. 출발지 포트와 목적지 포트는 TCP 세그먼트 헤더에 포함되어 있다.
TCP와 IP는 빈튼 서프(Vinton Cerf)와 로버트 칸(Robert Kahn)이 1973년경 처음 설계했고, 이들은 2004년 튜링상을 공동 수상했다. TCP/IP는 지금까지 여러번 개선을 거쳤지만, 초기의 훌륭한 설계 덕에 네트워크 규모와 트래픽 속도가 엄청나게 증가했음에도 본질적으로는 그대로다.
68. 최상위 프로토콜: 메일 전송과 파일 공유
TCP는 두 컴퓨터 간 데이터를 주고 받는 신뢰성 있는 양방향 스트림을 제공한다. 인터넷 서비스와 애플리케이션은 TCP를 전송 메커니즘으로 사용하면서, 다른 기능들에 대해선 또 다른 프로토콜들을 갖는다.
HTTP
HTTP(Hypertext Transfer Protocol, 하이퍼텍스트 전송 프로토콜)는 웹 브라우저와 서버에 사용되는 프로토콜로, 사용자가 브라우저에서 링크를 클릭하면 브라우저는 서버의 80번 포트에 대해 TCP/IP 연결을 열고 특정 페이지를 요청하는 짧은 메시지를 보낸다. 메시지는 브라우저라는 애플리케이션을 타고 TCP, IP를 거쳐 여러 물리 계층(전화선, 광케이블, 이더넷 등)을 거쳐 여러 게이트웨이를 통해 서버 컴퓨터로 전달된다. 그러면 서버 컴퓨터는 페이지를 준비한 다음, 페이지 인코딩 방식에 대한 정보 등 약간의 추가 데이터와 함께 페이지를 사용자에게 보낸다. 정보가 다시 사용자에게 돌아오는 경로는 원래 경로와 다를 수도 있다. 브라우저는 이 응답을 읽고 정보를 이용해 페이지 내용을 표시한다.
SMTP: 단순 메일 전송 프로토콜
우리는 보통 브라우저를 통해 메일을 보내고 받는데, 이러한 메일 서비스 표면 아래에도 몇 개의 계층이 있으며 각 계층은 프로그램과 프로토콜로 작동된다. 메일 서비스는 기본적으로 2가지의 프로토콜에 기반한다.
우선 SMTP(Simple Mail Transfer Protocol, 단순 메일 전송 프로토콜)는 다른 시스템과 메일을 교환하는데 사용된다. SMTP는 수신자의 컴퓨터 25번 포트로 TCP/IP 연결을 설정한 다음, 프로토콜 내용에 따라 발신자와 수신자를 식별하고 메시지를 전송한다.
SMTP는 메일 메시지를 아스키코드 텍스트로 받기 때문에, 다른 종류의 데이터를 텍스트로 변환하는 방법이 필요하다. 이런 변환 방법 및 여러 개의 조각을 하나의 메일 메시지로 결합하는 방법을 적은 표준이 MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장)이다. MIME은 사진이나 비디오 같은 첨부 파일을 메일에 포함하는데 사용되고, HTTP에서도 쓰인다.
SMTP는 출발지와 목적지 간을 연결해주는 end-to-end 프로토콜이지만, 그 아래에 있는 TCP/IP 패킷은 출발지에서 목적지로 가는 도중에 15~20개의 게이트웨이를 통과한다. 경로상의 게이트웨이는 패킷을 조사하거나 사본을 만들 수도 있다. 따라서 메일의 보안을 위해서는 출발지에서 암호화해야한다. 다만, 메일 내용을 암호화해도 발신자와 수신자는 숨겨지지 않고, 트래픽 분석을 하면 누가 누구와 통신 중인지 알 수 있다.
SMTP가 메일을 전송하는 프로토콜이라면, 메일을 읽는 과정에서 쓰이는 프로토콜은 IMAP(Internet Message Access Protocol, 인터넷 메시지 접근 프로토콜)이다. IMAP을 사용하면 메일이 서버에 남기 때문에 수신자가 여러 곳에서도(브라우저, 휴대폰 등) 메일에 접근할 수 있고, 어떤 메일을 읽었는지 안 읽었는지 등 우편함이 일관된 상태로 유지될 수 있다.
메일은 주로 Gmail이나 Outlook 같은 시스템에 의해 클라우드에서 처리되는데, 이런 시스템들의 내부에서 메일 전송을 위해선 SMTP가 사용되고 클라이언트 접근에선 IMAP처럼 동작한다.
파일 공유와 P2P 프로토콜
1999년 6월, Shawn Fanning은 MP3 포맷으로 압축된 음악을 쉽게 공유할 수 있는 프로그램인 Napster를 공개했다. 냅스터를 사용하려면 우선 냅스터 클라이언트 프로그램을 컴퓨터에 설치한다. 클라이언트는 공유할 파일을 담을 로컬 폴더를 생성하고, 클라이언트가 냅스터 서버에 로그인하면 클라이언트는 공유 파일의 '이름'을 업로드했고 냅스터 서버는 현재 이용 가능한 파일 이름을 담고 있는 중앙 디렉터리에 그 이름을 추가했다.
사용자가 중앙 디렉터리에서 가수나 곡 제목을 검색하면 냅스터는 현재 온라인 상태이면서 해당 파일을 공유할 의지가 있는 다른 사용자의 목록을 제공했다. 사용자가 파일 공급자를 선택하면 냅스터는 IP 주소와 포트 번호를 제공해 두 이용자를 접선해줬고, 사용자 컴퓨터의 클라이언트 프로그램이 공급자와 직접 접촉하여 파일을 가져왔다. 중앙 서버는 음악 파일 자체는 전혀 건드리지 않았다.
이는 브라우저(클라이언트)가 웹사이트(서버)에 뭔가 요청하는 클라이언트-서버 모델과는 다른, 한 냅스터 사용자가 다른 냅스터 사용자에게 파일을 전송하는 P2P(peer-to-peer) 모델이다. 음악 자체는 유저들의 컴퓨터에만 저장되었고 중앙 서버는 음악 파일을 저장하지 않았으나, 법적으로 저작권 문제를 피해갈 수는 없었다.
최신 파일 공유 서비스는 2001년 Bram Cohen이 개발한 비트토렌트(BitTorrent)라는 P2P 프로토콜을 이용한다. 비트토렌트는 파일을 다운로드하는 각각의 사용자들이 같은 파일을 다운로드하려는 다른 사람에게도 본인이 가진 파일 조각을 업로드해야 하는 방식이다. 비트토렌트에서는 분산된 디렉터리를 이용해 파일을 찾고, 용량이 작은 토렌트 파일을 사용해 누가 어떤 블록을 보내고 받았는지 기록을 유지하는 트래커(비트토렌트 프로토콜을 사용하는 피어 간의 통신을 지원하는 서버)를 식별한다. 따라서 다운로드만 하려는 사람도 프로토콜 요구사항에 따라 파일 조각을 업로드해야 하고, 이에 저작권 침해 탐지에 걸리기 쉽다.
69. 디지털 저작권 논쟁
1990년대 들어서 책이나 음반의 디지털 사본이 만들기 쉬워짐에 따라 디지털 저작권 문제가 생겨났다. 이에 미국에선 1998년, DMCA(Digital Millennium Copyright Act, 디지털 밀레니엄 저작권법)이 제정된다. DMCA는 인터넷 상에서 저작권이 있는 자료를 배포하는 것을 금지한다. 또, 디지털 미디어 저작권 보호 기술을 우회하는 방법을 쓰는것도 금지한다.
DMCA는 ISP들에 면책(safe harbor) 조항을 제공한다. 즉, 저작권자가 ISP에 자신의 저작권이 침해당하고 있다고 통보했을 때, ISP가 침해자에게 해당 자료를 삭제하라고 요구하면 ISP는 저작권 침해에 대한 책임을 지지 않는다.
꼭 ISP가 아니더라도 이러한 면책 조항은 적용된다. 예를 들어 대학에서도 웹사이트에 저작권 침해 자료가 올라온다면, 대학은 신고 받았을 때 침해자에게 해당 자료를 지우라고 요구하면 책임에서 벗어난다.
2004년에 구글은 대학/학술 도서관에서 보유하고 있는 많은 책을 스캔하는 프로젝트를 시작했는데, 2005년 미국 작가 협회가 구글에 소송을 제기한다. 이 소송은 2013년까지 이어졌고, 결과는 구글의 무죄 판결이었다. 판결의 근거는 구글이 이러한 활동을 함으로써 소실될 가능성이 있는 책을 보존하고, 원활한 학문 연구를 위해 자료를 디지털 포맷으로도 이용할 수 있게 했으며, 이로 인해 저자와 출판사들도 수입을 창출할 수 있다는 것이었다.
이 사례에서 알 수 있듯이, 사실 저작권 관련 분쟁에서는 양측 모두 합리적인 주장을 내놓을 수 있다. 작가들은 사람들이 복제판을 다운로드하기보다는 자신이 쓴 책을 합법적인 방법으로 구매하기를 바랄 것이고, 연구자들은 쉽게 찾아볼 수 없는 책들을 쉽게 검색할 수 있어 디지털화를 반길 것이다.
70. 보안에 취약한 IoT 기기들
오늘날 수많은 디지털 장치들엔 강력한 프로세서와 메모리가 있고, 무선 네트워크 연결도 지원된다. 그리고 무선 네트워크 연결에 필요한 모든 메커니즘은 이미 마련되어 있고 비용도 아주 낮기 때문에 카메라, 자동차, 온도 조절 장치, 비디오 모니터, 음성 응답 시스템, 전구 등 수많은 전자 제품들은 인터넷 연결을 기반으로 보다 다양한 기능을 제공하는데, 이런 제품들, 또는 시스템을 IoT(Internet of Things, 사물 인터넷)라고 한다. 간단히 말하면 다양한 기기에 통신 기능이 있어 인터넷을 통해 상호 통신하는 기기, 또는 그 시스템이다.
정보통신기술 기반으로 모든 사물을 연결해 사람과 사물, 사물과 사물간에 정보를 교류하고 상호 소통하는 지능형 인프라 및 서비스 기술
-과학기술정보통신부의 사물인터넷에 대한 정의-
IoT는 아주 훌륭한 아이디어이지만, 특정 용도를 가진 장치(카메라, 스피커, 모니터 등)이기에 범용 컴퓨팅 장치보다는 보안 문제에 더 취약하다. 즉, 해킹이나 불법 침해에 취약하다는 단점이 있다.
71. 요약
인터넷은 패킷 네트워크로, 정보가 표준화된 패킷으로 전송되어 여러 개의 네트워크를 통과하며 동적으로 라우팅된다. 이는 전화 시스템에서 대화마다 전용 회선이 있는 것과는 다른 모델이다.
인터넷은 현재 연결된 각 호스트에 고유한 IP 주소를 할당하고, 같은 네트워크에 있는 호스트들은 공통 IP 주소 접두사(prefix)를 공유한다. DHCP로 인해 노트북과 휴대전화 같은 모바일 호스트는 연결될 때마다 IP 주소가 달라지고, 위치가 바뀌면서 달라지기도 한다. DNS는 도메인 네임을 IP 주소로 변환하거나 그 반대로 변환하는 대규모 분산 데이터베이스이다.
네트워크는 게이트웨이들로 연결되어 있다. 게이트웨이는 패킷이 한 네트워크에서 다른 네트워크로 라우팅할 수 있게 해주는 컴퓨터다.
인터넷은 프로토콜에 따라 작동하는데, 그 중 핵심 프로토콜은 IP와 TCP이다. IP는 정보를 교환하기 위한 인터넷의 공통 메커니즘으로, 이더넷과 무선 시스템 같은 특정 하드웨어 기술은 IP 패킷을 캡슐화하여 전송한다. TCP는 IP를 사용하여 호스트의 특정 포트로 연결되는 안정적인 스트림을 만든다. 이들보다 상위 레벨 프로토콜은 TCP/IP를 사용하여 서비스를 제공한다.
프로토콜을 계층화하는 것도 인터넷 작동에서의 핵심적인 원리다. 계층화는 구현 세부 사항을 숨기면서 복잡성을 조직화하고 통제하는 기법이다. 각 계층은 자신이 해야할 일만을 집중적으로 수행하고, 바로 아래 계층에서 제공하는 서비스는 이용하고 바로 윗 계층에 서비스를 제공한다. 예를 들어, 하드웨어 네트워크는 네트워크 상의 한 컴퓨터에서 다른 컴퓨터로 바이트를 옮기고, 그 위 계층인 IP는 인터넷을 통해 개별 패킷을 옮긴다. 그 위의 TCP는 IP로부터 안정적인 스트림을 만들고, 그 위의 애플리케이션 프로토콜은 스트리밍 사에서 데이터를 보내고 받는다.
이러한 프로토콜들의 공통점은 컴퓨터 프로그램 간에 정보를 옮긴다는 점인데, 이를 위해 인터넷을 무지능 네트워크(dumb network)로 활용한다. 즉, 인터넷은 바이트를 해석/처리하진 않고 그냥 효율적으로 데이터를 복사하기만 하는 수단으로 쓴다는 뜻이다. 이를 다른 표현으로 인터넷이 단대단 원칙(end-to-end principle)을 따른다고도 한다. 즉, 해석/처리하는 지능은 데이터를 보내고 받는 최종점들에만 있다는 뜻이다. 이러한 특성은 전통적인 전화망과 다른 것으로, 전화망에선 모든 지능이 네트워크에 있었고, 전화기 같은 종단점은 음성을 전달하는 것 이상의 기능은 하지 못했다. 무지능 네트워크 모델은 매우 생산적이었는데, 좋은 아이디어가 있는 사람들이 똑똑한 종단점을 만들고, 바이트를 전달하는 것 같은 단순한 작업을 네트워크에 맡길 수 있기 때문이다.
인터넷에서 프라이버시와 보안을 지키는 것은 어렵다. 많은 네트워킹 기술이 브로드캐스트 방식을 사용하는데, 이는 도청에 취약하다. 유선 이더넷이나 광케이블상에서 공격하려면 해당 케이블을 찾아 물리적으로 연결해야 하지만, 무선으로 하는 공격은 스누핑을 하려고 하면 그저 일정 거리 내에만 있으면 된다.
또, 인터넷은 전반적인 구조와 개방성 면에서 정부 통제에 취약한데, 특정 국가 안팎을 오가는 정보 흐름이 차단되거나 국가 방화벽이 도입되면 보편 네트워크라는 가치가 훼손되기 때문이다.
🤠 개인탐구
OSI 표준 모델
원문은 Open Systems Interconnection Reference Model로, 국제표준화기구(ISO)에서 개발한 모델로, 7 계층으로 나뉘기 때문에 OSI 7 계층이라고도 부른다. 이 모델은 네트워크 프로토콜들과 장비들이 어떤 역할을 맡고 있는지 이해하고 설계하는 기준이 된다.
계층 | 이름 | 핵심 역할 | 실제 프로토콜/기술 |
---|---|---|---|
7계층 | 응용 계층(Application) | 사용자와 직접 상호작용하는 애플리케이션 | HTTP, FTP, DNS, SMTP |
6계층 | 표현 계층(Presentation) | 데이터 포맷 변환, 암호화, 압축 | JPEG, MPEG, SSL, TLS |
5계층 | 세션 계층(Session) | 세션 연결/유지/종료 | NetBIOS, RPC |
4계층 | 전송 계층(Transport) | 데이터 신뢰성, 순서 보장 | TCP, UDP |
3계층 | 네트워크 계층(Network) | 목적지까지 경로 설정 (IP 주소 기반) | IP, ICMP, ARP |
2계층 | 데이터 링크 계층(Data Link) | 같은 네트워크 내의 데이터 전송 | Ethernet, Wi-Fi, MAC 주소 |
1계층 | 물리 계층(Physical) | 전기/광 신호를 통한 실제 데이터 전송 | 케이블, 전파, 광섬유, 허브 |
파일 전송을 예로 들면 아래와 같다.
-
7계층 (응용) – 사용자가 파일 전송 요청 (ex. 이메일, 웹)
-
6계층 (표현) – 파일을 텍스트/이미지/암호화 등 표현 형식으로 변환
-
5계층 (세션) – 상대방과 연결 세션 생성
-
4계층 (전송) – 데이터를 나누고 TCP로 신뢰성 확보
-
3계층 (네트워크) – IP 주소 기반으로 목적지 경로 결정
-
2계층 (데이터 링크) – 이더넷 프레임 구성, MAC 주소 설정
-
1계층 (물리) – 0과 1의 신호로 데이터를 실제 전송
7개나 되다보니 외우는 방법이 있을 정도인데, Please Do Not Throw Sausage Pizza Away(Physical, Data Link, Network, Transport, Session, Presentation, Application)으로 외운다고 한다.
MAC 주소
MAC(Media Access Control Address)는 네트워크 장비(노트북, 스마트폰, 라우터 등)에 물리적으로 할당된 고유 식별자이다. 주로 제조사에서 장비에 하드코딩되어 나오기 때문에 기본적으로 변하지 않는다.
보통 16진수 12자리로 표현되고, :
또는 -
로 구분된다. 예를 들어, 00:1A:2B:3C:4D:5E
식인데, 앞의 6자리는 제조사 식별 코드(OUI, Organizationally Unique Identifier)이고 뒤의 6자리가 장비 고유의 일련 번호이다.
MAC 주소는 주로 로컬 네트워크(LAN)에서 사용되는데, 같은 네트워크 안에서 데이터를 어떤 장치에게 보낼지 판단할 때 사용된다. 예를 들면 Wi-Fi 공유기에서 여러 기기 중 하나에게만 데이터를 전달해야 할 때 사용된다.
3-Way Handshake
TCP 연결을 시작할 때 클라이언트와 서버가 서로 통신할 준비가 되었는지 확인하고 연결을 맺는 과정이다. 총 3번의 메시지 교환이 오가서 '3-way'라고 불린다.
- 1단계 : 클라이언트 -> 서버(SYN)
- 클라이언트가 서버에게 연결을 요청한다.
- 이 때,
SYN
(synchronize) 플래그가 설정된 패킷을 보낸다. - 클라이언트는 자신의 초기 시퀀스 번호(ISN)도 함께 보낸다.
클라이언트 -> 서버 : SYN, seq = x
- 2단계 : 서버 -> 클라이언트(SYN-ACK)
- 서버가 연결 요청을 수락하며 응답한다.
SYN
플래그 +ACK
(acknowledgment) 플래그가 동시에 설정된다.- 서버도 자신의 ISN = y를 보낸다.
- 동시에 클라이언트의 ISN에 +1한 값을 ACK로 응답한다.
서버 -> 클라이언트 : SYN, ACK, seq = y, ack = x+1
- 3단계 : 클라이언트 -> 서버(ACK)
- 클라이언트가 서버의 응답을 인정하고 최종 확인한다.
- ACK 플래그가 설정되고, 서버의 시퀀스 번호 +1로 응답한다.
클라이언트 -> 서버 : ACK, seq = x+1, ack = y+1
4-Way Handshake
3-Way Handshake가 TCP 연결을 설정하는 과정이면, 4-Way Handshake는 TCP 연결을 정상적으로 종료하는 과정이다. 연결의 설정에는 한쪽(클라이언트)이 요청하면 다른쪽(서버)이 수락하기만 하면 되어 3번이면 충분하지만, 종료에는 클라이언트와 서버가 각각 따로 종료 의사를 밝혀야 하기 때문에 4-Way가 되었다. 즉, 클라이언트가 "이제 데이터 요청 끝, 연결 종료"라고 요청해도 서버 쪽에서 "아직 보낼거 있음, 연결 유지"라고 하면 연결이 유지되기 때문에 각 방향의 연결은 독립적으로 종료되어야 한다.
- 1단계 : 클라이언트 -> 서버 (FIN)
- 클라이언트가 연결 종료 요청(
FIN
)을 보낸다.
클라이언트 -> 서버: FIN, seq = x
- 2단계 : 서버 -> 클라이언트 (ACK)
- 서버가
FIN
요청을 확인하고ACK
응답한다. - 하지만 이 시점에 서버는 아직 보낼게 있을 수도 있다.
서버 -> 클라이언트: ACK, ack = x+1
- 3단계 : 서버 -> 클라이언트 (FIN)
- 서버도 보낼 데이터가 없으니 연결 종료한다는 요청(
FIN
)을 보낸다.
서버 -> 클라이언트: FIN, seq = y
- 4단계 : 클라이언트 -> 서버 (ACK)
- 클라이언트가 서버의 종료 요청을 확인하고
ACK
응답한다.
클라이언트 -> 서버: ACK, ack = y+1
종료 이후, 클라이언트는 마지막 ACK
를 보내고 TIME_WAIT 상태에 들어간다. 이후, 이 상태에서 최대 2분 정도 기다린 후 완전히 종료된다. TIME_WAIT 상태는 지연된 패킷이 네트워크에 남아 서버에 영향을 주는 것을 방지하기 위해 존재한다.