[CS Study] - 5주차

• OSI 7계층
• GET, POST 방식의 차이점
• TCP 3-way-handshake / 4-way-handshake
• TCP와 UDP의 차이점
• TCP/IP 흐름제어 & 혼잡제어

7계층으로 나누는 이유

계층을 나눈 이유는 통신이 일어나는 과정을 단계별로 파악할 수 있기 때문이다.

흐름을 한눈에 알아보기 쉽고, 사람들이 이해하기 쉽고, 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건드리지 않고도 이상이 생긴 단계만 고칠 수 있기 때문이다.

OSI 7계층

네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말한다.

1. 물리(Physical)

리피터, 케이블, 허브 등

전기적 신호가 나가는 물리적인 장비로, 물리 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하게 된다. 단지 데이터를 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간이다. 즉, 데이터를 전송하는 역할만 진행한다.

데이터를 전달할뿐, 전송하려는 (또는 받으려는) 데이터가 무엇인지, 어떤 에러가 있는지 등에는 전혀 신경 쓰지 않는다.

이 계층에서 사용되는 통신 단위는 비트이며 이는 0과 1로 나타내어지는, 즉 전기적으로 On Off 상태라고 생각하면 된다.

2. 데이터 링크(Data Link)

브릿지, 스위치 등

물리계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다. 따라서 통신에서의 오류도 찾아주고 재전송하는 기능을 가지고 있는 것이다.

이 계층에서는 Mac 주소를 가지고 통신한다. 전송하는 단위를 프레임이라고 하고, 프레임에 Mac 주소를 부여하고 에러 검출, 재전송, 흐름제어를 진행한다.
즉, 브릿지나 스위치를 통해 Mac 주소를 가지고 물리 계층에서 받은 정보를 전달하는 역할이다.

데이터 링크 계층은 포인트 투 포인트 간 신뢰성있는 전송을 보장하기 위한 계층으로 CRC 기반의 오류 제어와 흐름 제어가 필요하다. 네트워크 위의 개체들 간 데이터를 전달하고, 물리 계층에서 발생할 수 있는 오류를 찾아내고, 수정하는 데 필요한 기능적, 절차적 수단을 제공한다.
주소 값은 물리적으로 할당 받는데, 이는 네트워크 카드가 만들어질 때부터 Mac 주소가 정해져 있다는 뜻이다. 주소 체계는 계층이 없는 단일 구조이다. 데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다. 이 외에도 HDLC나 ADCCP 같은 포인트 투 포인트 프로토콜이나 패킷 스위칭 네트워크나 LLC, ALOHA 같은 근거리 네트워크용 프로토콜이 있다. 네트워크 브릿지나 스위치 등이 이 계층에서 동작하며, 직접 이어진 곳에만 연결할 수 있다.

3. 네트워크(Network)

라우터, IP

경로(Route)와 주소(IP)를 정하고 패킷을 전달해주는 것이 이 계층의 역할이다. 이 계층에서 가장 중요한 기능은 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능 (라우팅) 이다. 따라서 최적의 경로를 설정해야 한다. 여기에 사용되는 프로토콜의 종류도 다양하고, 라우팅 하는 기술도 다양하다.

대표적인 장비는 라우터이며, 요즘은 2계층의 장비 중 스위치에 라우팅 기능을 장착한 Layer3 스위치도 있다.

네트워크 계층은 여러개의 노드를 거칠때마다 경로를 찾아주는 역할을 하는 계층으로 다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질(QoS)을 제공하기 위한 기능적, 절차적 수단을 제공한다.

네트워크 계층은 라우팅, 흐름 제어, 세그멘테이션, 오류 제어, 인터네트워킹 등을 수행한다. 데이터를 연결하는 다른 네트워크를 통해 전달함으로써 인터넷이 가능하게 만드는 계층이다. 논리적인 주소 구조(IP), 네트워크 관리자가 직접 주소를 할당하는 구조를 가지며, 계층적이다.

또한, 서브네트의 최상위 계층으로 경로를 설정하고, 개방형 시스템들의 사이에서 네트워크 연결을 설정, 유지, 해제하는 기능을 부여하고, 전송 계층 사이에 네트워크 서비스 데이터 유닛(NSDU: Network Service Data Unit)을 교환하는 기능을 제공한다.

IP 계층
TCP/IP 상에서 IP 계층이란 네트워크의 주소 (IP 주소)를 정의하고, IP 패킷의 전달 및 라우팅을 담당하는 계층

OSI 7계층 모델의 관점에서 보면 IP 계층은 네트워크 계층에 해당한다. 즉, 패킷을 목적지까지 전달하는 역할과 그에 수반되는 기타 역할을 한다.

IP 계층의 주요 역할

• IP 계층에서는 그 하위 계층인 데이터링크 계층의 하드웨어적인 특성에 관계없이 독립적인 역할을 수행한다.

IP 계층 상에 있는 주요 프로토콜

• 패킷의 전달을 책임지는 IP
• 패킷 전달 에러의 보고 및 진단을 위한 ICMP
• 복잡한 네트워크에서 인터네트워킹을 위한 경로를 찾게 해주는 라우팅 프로토콜

IP 프로토콜
TCP/IP 기반의 인터넷 망을 통하여 데이터그램의 전달을 담당하는 프로토콜

1. 주요 기능

• IP 계층에서 IP 패킷의 라우팅 대상이 된다.
• IP 주소 지정

2. 주요 특징

• '신뢰성' 및 '흐름 제어' 기능이 전혀 없다. → Best-Effort Service
• 신뢰성을 확보하려면 IP 계층 위의 TCP와 같은 상위 트랜스포트 계층에 의존해야 한다.
• 비연결성 데이터그램 방식으로 전달되는 프로토콜 → Connectionless
• 패킷의 완전한 전달 (소실, 중복, 지연, 순서바뀜 등이 없게 함)을 보장하지 않는다. → Unreliable
• IP 패킷 헤더 내 수신 및 발신 주소를 포함한다. → IPv4 헤더, IPv6 헤더, IP 주소
• IP 헤더 내 바이트 전달 순서: 최상위 바이트(MSB)를 먼저 보낸다. → Big-endian
• 경우에 따라, 단편화가 필요하다. → IP 단편화 참조
• TCP, UDP, ICMP, IGMP 등이 IP 데이터그램에 실려서 전송된다.

4. 전송(Transport)

TCP, UDP

통신을 활성화하기 위한 계층이다. 보통 TCP 프로토콜을 이용하며, 포트를 열어서 응용프로그램들이 전송을 할 수 있게 한다. 만약 데이터가 왔다면 4계층에서 해당 데이터를 하나로 합쳐서 5계층에 던져준다.

전송 계층은 양 끝단의 사용자들이 신뢰성있는 데이터를 주고 받게 해주는 역할을 하며, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다. 전송 계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고(stateful), 연결 기반(connection oriented) 이다. 이는 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들을 다시 전송한다는 것을 뜻한다. 가장 잘 알려진 전송 계층의 예는 TCP이다.

종단간(end-to-end) 통신을 다루는 최하위 계층으로 송신자와 수신자 간의 신뢰성 있고 효율적인 데이터를 전송하기 위하여 오류검출 및 복구, 흐름제어와 중복 검사 등을 수행한다.

데이터 전송을 위해서 Port 번호가 사용된다. 대표적인 프로토콜로는 TCP와 UDP가 있다.

TCP 프로토콜 (Transmission Control Protocol)
OSI 계층모델의 관점에서 전송 계층(4계층)에 해당한다.

양종단 호스트 내 프로세스 상호 간에 신뢰적인 연결지향성 서비스를 제공한다.
IP의 비신뢰적인 최선형 서비스에다가 신뢰적인 연결지향성 서비스를 제공한다. 신뢰적인 전송을 보장함으로써, 어플리케이션 구현이 한층 쉬워지게 된다.

1. 신뢰성 있음 (Reliable)

• 패킷 손실, 중복, 순서 바뀜 등이 없도록 보장
• TCP 하위 계층인 IP 계층의 신뢰성 없는 서비스에 대해 다방면으로 신뢰성을 제공

2. 연결지향적 (Connection-oriented)

• 같은 전송 계층의 UDP가 비연결성(Connectionless)인 것과 달리, TCP는 연결지향적이다.
• 연결 관리를 위한 연결 설정 및 연결 해제가 필요하다 → TCP 연결 설정, TCP 연결 종료
• 양단간 어플리케이션/프로세스는 TCP가 제공하는 연결성 회선을 통하여 서로 통신

UDP 프로토콜 (User Datagram Protocol)
전송 계층의 통신 프로토콜의 하나이다. (TCP에 대비됨)
신뢰성이 낮은 프로토콜로써 완전성을 보증하지 않으나, 가상회선을 굳이 확립할 필요가 없고 유연하며 효율적 응용의 데이터 전송에 사용된다.

1. 비연결성이고, 신뢰성이 없으며, 순서화되지 않은 Datagram 서비스 제공

• 메세지가 제대로 도착했는지 확인하지 않는다. (확인응답 없음)
• 수신된 메세지의 순서를 맞추지 않는다. (순서제어 없음)
• 흐름 제어를 위한 피드백을 제공하지 않는다. (흐름제어 없음)
• 검사합을 제외한 특별한 오류 검출 및 제어가 없다. (오류제어 거의 없음) → UDP를 사용하는 프로그램 쪽에서 오류제어 기능을 스스로 갖춰야 한다.
• 데이터그램 지향의 전송계층용 프로토콜이다. (논리적인 가상회선 연결이 필요없음)

2. 실시간 응용 및 멀티캐스팅 가능

• 빠른 요청과 응답이 필요한 실시간 응용에 적합하다.
• 여러 다수 지점에 전송이 가능하다. (1:多)

3. 헤더가 단순함

• UDP는 TCP 처럼 16 비트의 포트 번호를 사용하나, 헤더는 고정크기의 8 바이트 (TCP는 20 바이트) 만 사용한다. 즉, 헤더 처리에 많은 시간과 노력을 요하지 않는다.

5. 세션(Session)

API, Socket

데이터가 통신하기 위한 논리적인 연결을 말한다. 통신을 하기위한 대문이라고 보면 된다. 하지만 4계층에서도 연결을 맺고 종료할 수 있기 때문에 우리가 어느 계층에서 통신이 끊어졌나 판단하기에는 한계가 있다. 그러므로 세션 계층은 4계층과 무관하게 응용 프로그램 관점에서 봐야 한다. 세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능이 있다.

세션 계층은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 동시 송수신 방식(Duplex), 반이중 방식(half-duplex), 전이중 방식(full-duplex)의 통신과 함께 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다.
이 계층은 TCP/IP 세션을 만들고 없애는 역할을 한다.

6. 표현(Presentation)

JPEG, MPEG 등

전송하는 데이터의 표현방식을 결정한다. (예: 데이터 변환, 압축, 암호화 등)

표현 계층은 3가지 기능을 가지고 있다.
1. 송신자에서 온 데이터를 해석하기 위한 응용계층 데이터 부호화, 변화
2. 수신자에서 데이터의 압축을 풀 수 있는 방식으로 된 데이터 압축
3. 데이터의 암호화와 복호화

인코딩이나 암호화 등의 동작이 표현계층에서 이루어진다.

7. 응용(Application)

HTTP, FTP, DNS 등

사용자와 가장 가까운 계층이 응용 계층이다. 즉, 최종 목적지로써 HTTP, FTP, SMTP, POP3, IMAP, Telnet 등과 같은 프로토콜이 있다. 해당 통신 패킷들은 위에 나열한 프로토콜에 의해 모두 처리되며 우리가 사용하는 브라우저나, 메일 프로그램은 프로토콜을 보다 쉽게 사용하게 해주는 응용프로그램이다. 한마디로 모든 통신의 양 끝단은 HTTP와 같은 프로토콜이지 응용 프로그램이 아니다.

응용 계층은 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다. 일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다.

HTTP 프로토콜 (HyperText Transfer Protocol)
웹 상에서 웹 서버 및 웹 브라우저 상호 간의 데이터 전송을 위한 응용계층 프로토콜이다. 처음에는 WWW 상의 하이퍼텍스트 형태의 문서를 전달하는데 주로 이용했다. 현재에는 이미지, 비디오, 음성 등 거의 모든 형식의 데이터 전송이 가능하다.

1. 요청 및 응답의 구조

• 동작 형태가 클라이언트/서버 모델로 동작

2. 메시지 교환 형태의 프로토콜

• 클라이언트와 서버 간에 'HTTP 메시지'를 주고받으며 통신
• SMTP 전자메일 프로토콜과 유사
• HTTP의 응답 및 요청 메시지 구성

3. 트랜잭션 중심의 비연결성 프로토콜

• 종단간 연결이 없음 (Connectionless)
• 이전의 상태를 유지하지 않음 (Stateless)

4. 전송계층 프로토콜 및 사용 포트 번호

• 전송계층 프로토콜: TCP
• 사용 포트 번호: 80번

들어가기 전에

사용자가 어떤 홈페이지로 이동하기 위해서 URL을 브라우저 주소창에 작성하고 엔터를 누르면 원하는 페이지로 이동한다. 사용자는 단순히 URL(Uniform Resource Locator)을 입력하였을 뿐이지만 서버 내부에서는 클라이언트의 요청에 응답(웹페이지로 표현)하기 위해서 처리를 해주어야 한다.

여기서 클라이언트가 서버로 요청을 보내는 방법인 HTTP Method에는 크게 2가지 방식이 있는데, 이것이 GET 방식과 POST 방식이다.

GET과 POST 방식의 차이점에 대해 알아보기 전에 먼저, 각 방식에 대해 정확히 아는게 좋을 것 같다. GET과 POST의 각각의 특징과 역할들에 대해 먼저 알아보겠다.

GET과 POST는 HTTP 메서드로 클라이언트에서 서버로 무언가를 요청할 때 사용한다.

즉, GET은 서버에서 어떤 데이터를 가져와서 보여줄 때 사용한다. 어떤 값이나 내용, 상태등을 바꾸지 않는 경우에 사용하는 것이다. 이에 비해, POST는 서버상의 데이터의 값이나 상태를 바꾸기 위해서 사용한다.

게시판으로 예를 들자면, 글의 내용에 대한 목록을 보여주는 경우나, 글의 내용을 보는 경우는 GET에 해당한다. 그리고 글의 내용을 저장하고, 수정할 때 POST를 사용하는 것이다.

HTTP

GET 방식과 POST 방식에 대해 알아보기 위해서는 HTTP 프로토콜에 대해 알고 있어야 된다. HTTP (Hypertext Transfer Protocol)란 하이퍼텍스트 전송 규약으로 Web-Client와 Web-Server간 데이터를 전송하는 프로토콜이다. GET 메소드와 POST 메소드는 HTTP 프로토콜에서 데이터 전송을 위해 지원하는 7가지 메소드 중 일부이다.

HTTP 통신할 때 보내는 데이터는 HTTP 패킷이라 하는데 해당 패킷의 구조는 크게 Header 영역과 Body 영역으로 나누어 진다. Header에는 크게 여러가지 정보와 어떠한 방식의 메소드를 사용하였는지에 대해 적게 된다. 또한 어떠한 메소드 방식을 사용하였는지에 따라 Body 영역의 사용 유무 및 사용 방법이 달라지게 된다.

GET 이란?

GET은 클라이언트에서 서버로 어떠한 리소스로부터 정보를 요청하기 위해 사용되는 메서드이다.

좀 더 쉽게 말하자면, 데이터를 읽거나(Read), 검색(Retrieve)할 때에 사용되는 메소드라고 할 수 있다.

예를들면 게시판의 게시물을 조회할 때 쓸 수 있다. GET을 통한 요청은 URL 주소 끝에 파라미터로 포함되어 전송되며, 이 부분을 쿼리 스트링 (Query string) 이라고 부른다. 방식은 URL 끝에 "?"를 붙이고 그 다음 변수명1=값1&변수명2=값2... 형식으로 이어 붙이면 된다. URL에 Parameter를 전송하기 때문에 body 영역을 사용하지 않는다.

예를 들어, 다음과 같은 방식이다.

www.example.com/show?name1=value1&name2=value2

위 예는 앞서 말한 쿼리 스트링을 포함한 URL이다. 파라미터인 name1과 name2를 통해 값을 전달받을 수 있다. 만약, 요청 파라미터가 여러 개이면 &로 연결한다.

그리고 GET 요청은 오로지 데이터를 읽을 때만 사용되고 수정할 때는 사용되지 않는다. 따라서 이러한 이유로 인해 사용하면 안전하다고 간주된다. 즉, 데이터 변형의 위험없이 사용할 수 있다는 의미이다.

GET의 특징

• GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.
  GET을 통해 서버에 리소스를 요청할 때 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드 하는 대신, 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.
• GET 요청은 브라우저 히스토리에 남는다.
• GET 요청을 북마크에 추가할 수 있다.
• POST 방식보다 상대적으로 전송 속도가 빠르다.
• GET 요청에는 데이터 길이에 대한 제한이 있다.
  GET 요청의 길이 제한은 표준이 따로 있는건 아니고 브라우저마다 제한이 다르다고 한다.
• 파라미터에 내용이 노출되기 때문에 민감한 데이터를 다룰 때 GET 요청을 사용해서는 안된다.
• GET은 데이터를 요청할 때만 사용된다.
• GET 요청은 성공시 200(OK) HTTP 응답 코드를 XML, JSON 뿐만 아니라 여러 데이터(HTML, TXT 등..) 여러 형식의 데이터와 함께 반환한다.

GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다. → js, css, 이미지 같은 정적 컨텐츠는 데이터 양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없다. 그래서 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼서 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생한다. 이 때는 브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보낸다.

POST 란?

POST는 클라이언트에서 서버로 리소스를 생성하거나 업데이트 하기 위해 서버에 데이터를 보낼 때 사용되는 메서드이다.

예를 들면 게시판에 게시글을 작성하는 작업 등을 할 때 사용된다. POST는 전송할 데이터를 HTTP 메시지 body 부분에 담아서 서버로 보낸다. GET에서 URL의 파라미터로 보냈던 name1=value1&name2=value2가 body에 담겨 보내진다고 생각하면 된다.

POST로 데이터를 전송할 때 길이 제한이 따로 없어서 용량이 큰 데이터를 보낼 때 사용하거나, GET 처럼 데이터가 외부적으로 드러나는건 아니라서 보안이 필요한 부분에 많이 사용된다. 이처럼 POST는 데이터가 body로 전송되고, 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬의 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해서 전송해야 한다.

POST를 통한 데이터 전송은 보통 HTML Form을 통해 서버로 전송된다.

또한, POST로 데이터를 전송할 때에는 body 영역 데이터 타입을 Header Content-Type에 명시를 해줘야 한다.

POST의 특징

• POST 요청은 캐시되지 않는다.
• POST 요청은 브라우저 히스토리에 남지 않는다.
• POST 요청은 북마크에 추가할 수 없다.
• POST 요청은 데이터 길이에 제한이 없다.
• POST 요청 중 자원 생성은 201(Created) HTTP 응답 코드를 반환한다.
• 속도가 GET 방식보다 느리다.
• 서버로 보내기 전에 인코딩하고, 전송 후 서버에서는 다시 디코딩 작업을 한다.
• 쿼리스트링(문자열) 데이터 뿐만 아니라, 라디오 버튼, 텍스트 박스 같은 객체들의 값도 전송 가능하다.

GET, POST 방식의 차이점

위 사진은 GET과 POST의 리소스 전달 방식의 차이를 표현한 사진이다.

사용목적: GET은 서버의 리소스에서 데이터를 요청할 때, POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다. DB로 따지면 GET은 SELECT에 가깝고, POST는 CREATE에 가깝다고 보면된다.

요청에 body 유무: GET은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST는 body에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.

멱등성(idempotent): GET 요청은 멱등이며, POST는 멱등이 아니다.

멱등이란?
idempotent는 멱등법칙(冪等法則) 또는 멱등성(冪等性)이란 뜻으로, 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

너무 어렵게 생각하지 않아도 된다. 집중해야 할 부분은 딱 한 줄이다.
연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

즉, 멱등이라는 것은 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나야 한다는 것을 의미한다.

GET은 Idempotent, POST는 Non-idempotent하게 설계되었다.

여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미한다. 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용한다.

예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하게 된다.

반대로 POST는 Non-idempotent하기 때문에 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있다. 이에 따라 POST는 서버의 상태나 데이터를 변경시킬 때 사용된다.

게시글을 쓰면 서버에 게시글이 저장이 되고, 게시글을 삭제하면 해당 데이터가 없어지는 등 POST로 요청을 하게 되면 서버의 무언가는 변경되도록 사용된다. 이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE가 더 용도에 맞는 메소드라고 할 수 있다.

TCP 3-way-handshake / 4-way-handshake

3-way-handshake와 4-way-handshake는 연결을 성립하고 해제하는 과정을 말한다.

3 way handshake - 연결 성립
TCP는 정확한 전송을 보장해야 한다. 따라서 통신하기에 앞서, 논리적인 접속을 성립하기 위해 3 way handshake 과정을 진행한다.

1. 클라이언트가 서버에게 SYN 패킷을 보낸다. (sequence: x)
2. 서버가 SYN(x)를 받고, 클라이언트에게 받았다는 신호인 ACK와 SYN 패킷을 보낸다. (sequence: y, ACK: x+1)
3. 클라이언트는 서버로부터 ACK(x+1)와 SYN(y) 패킷을 받고, ACK(y+1)를 서버로 보낸다.

4 way handshake - 연결 해제
연결 성립 후, 모든 통신이 끝났다면 해제해야 한다.

1. 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
2. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. 이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다.
3. 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
4. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. 아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT를 통해 기다린다.
5. 서버는 ACK를 받은 이후 소켓을 닫는다. (Closed)
6. TIME_WAIT 시간이 끝나면 클라이언트도 닫는다. (Closed)

이렇게 4번의 통신이 완료되면 연결이 해제된다.

Reference

https://shlee0882.tistory.com/110
https://noahlogs.tistory.com/35
https://velog.io/@songyouhyun/Get%EA%B3%BC-Post%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%A5%BC-%EC%95%84%EC%8B%9C%EB%82%98%EC%9A%94
https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/
https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-GET%EA%B3%BC-POST-%EB%B0%A9%EC%8B%9D-%EB%B9%84%EA%B5%90