검색창에 www.google.com을 입력하면. 제일 먼저 해당 도메인의 ip주소를 얻기 위한 과정이 있었다. 이미 가지고 있는 캐시 정보를 찾아보고, 없는 경우 dns서버에 질의하여 ip 주소를 가져온다. 이 내용은 아래 포스팅에서 다루었다.
https://velog.io/@jeongye01/CSDNS%EB%9E%80
이제 이 ip주소를 통해 tcp 연결이 이루어진다.
TCP/IP 모델
우선 tcp/ip 모델에 대해서 간략하게 정리해 보았다.
데이터를 주고 받기 위해서는 이미 약속되어진 여러 프로토콜들을 사용하고 이들은 TCP/IP 모델에 의해 4계층으로 나누어진다.
- Application Layer : 응용 프로그램에서 데이터를 처리하는 계층 HTTP, HTTPS, POP3, SMTP, FTP 등
- Transport Layer : 데이터에 대한 검증, 재전송 등 각종 제어를 담당하는 계층 TCP, UDP
- Internet Layer:데이터를 목적지까지 효율적으로 전달하는 방법을 담당하는 계층 IP, ICMP 등
- Network Access Layer: 실질적으로(물리적으로) 데이터를 전송하는 계층 Ethernet, Wi-Fi 등
웹서비스를 통해 클라이언트와 서버가 통신을 한다고 가정하면,
Application Layer 에서 HTTP 프로토콜을 통해 HTTP Request와 Response를 주고 받게 된다 . 실제로 이 데이터들이 송수신되기 위해서는 우선 계층에 따라 데이터를 분리하고 캡슐화하게 된다. (http 프로토콜,tcp 프로토콜, ip 프로토콜, 이더넷 프로토콜을 사용하게 된다.)
- 우선 애플리케이션 프로그램은 메시지나 데이터 스트림을 인터넷 전송 계층 프로토콜인 TCP(Transmission Control Protocol)로 전송한다.
- transport layer에서 데이터 스트림은 segment로 분리되고, tcp 헤더를 부착한다. (패킷화)
- internet layer에서 목적지 ip 주소를 담은(dns를 통해 ip주소를 받아왔었다.) ip 헤더를 붙인다.
- network access layer에서 물리적 주소인 MAC주소(하드웨어마다 부여되는 주소.랜카드에서 확인가능.세상에 하나뿐인 주소.)가 포함된 이더넷 헤더를 부착해서 프레임화 한다.이때 ARP 프로토콜을 사용해서 ip주소를 mac주소로 변환할 수 있다.
캡슐화가 완료되면 데이터가 수신단에 물리적으로 이동하고 이를 받은 수신단이 역캡슐화를 통해 목적지 어플리케이션이 원래의 데이터를 받도록 한다.
TCP 프로토콜의 특징
- 연결 지향적(Connection-Oriented) : 데이터를 전송하기 전에 먼저 수신측과 연결을 설정해야 한다.
- 신뢰성 있는 전송(Reliable Transmission) :TPC는 전송 중 데이터의 손실이나 손상이 발생하면 해당 패킷을 재전송합니다. 이를 통해 데이터의 손실을 최소화하고 안정적인 전송을 보장
- 데이터 분할 및 조립 기능을 제공: TPC는 데이터를 일정한 크기의 패킷으로 분할하여 전송합니다. 이 때, 수신측에서는 이러한 패킷들을 조립하여 원래의 데이터로 복원
- 흐름 제어(Flow Control)를 지원: TPC는 수신측의 버퍼 상태에 따라 데이터를 전송하는 속도를 조절합니다. 이를 통해 수신측의 버퍼 오버플로우나 전송 속도의 불균형을 방지
- 혼잡 제어(Congestion Control)를 지원: TPC는 네트워크 상황에 따라 데이터 전송 속도를 조절하여 혼잡을 방지
- 양방향 데이터 전송을 지원: TPC는 양방향으로 데이터를 전송할 수 있는 프로토콜입니다. 이를 통해 양방향 통신이 가능해지며, 이를 이용하여 웹 브라우저와 서버 간의 통신 등에 사용
TCP 헤더
tcp 헤더는 아래와 같이 구성이 되어있다.
주요 부분들.
- 발신지 포트 주소
- 목적지 포트 주소
- Sequence Number (32 비트) : 바이트 단위로 구분되어 순서화되는 번호임->이를 통해, TCP에서는 신뢰성 및 흐름제어 기능 제공
- 6 개의 Flag bits(TCP 제어 플래그) (URG, ACK, PSH, RST, SYN, FIN): TCP 세그먼트 전달과 관련되어 TCP 회선 및 데이터 관리 제어 기능을 하는 플래그-> 관계된 기능 : 흐름제어,연결설정,연결종료,연결리셋,데이터전송모드
- SYN: TCP 연결 설정 시에 사용. SYN 비트가 설정된 패킷을 송신측에서 수신측으로 전송하면, 수신측에서는 SYN-ACK 패킷을 보내어 연결 설정을 요청하는 것을 응답
- ACK: ACK 비트는 데이터 전송 시 수신측에서 데이터를 정상적으로 수신했음을 보내는 비트
- FIN : TCP 연결 해제 시에 사용
TCP 연결+데이터 송수신
tcp프로토콜에서는 두 end-point가 3-way-handshaking을 통해 연결을 시작하고, 4-way-handshaking을 통해 연결이 종료 된다.
- 3 way handshaking(연결 시작,통신이 3번 발생)
- 데이터 송/수신
- 4 way handshaking(연결 종료,통신이 4번 발생)
3 way handshaking
우선 클라이언트는 서버에 연결을 요청하는 SYN 플래그가 설정된 시그먼트를 보낸다. 서버는 이 요청을 받아 ACK와 SYN플래그가 설정된 시그먼트를 보낸다. 그럼 클라이언트는 이어서 이 응답에 대한 ACK플래그가 설정된 시그먼트를 보냄으로써 연결이 시작된다. 그리고 이어서 데이터에 대한 시그먼트 송수신이 이루어 진다.
데이터 송/수신
클라이언트가 서버로부터 데이터가 담긴 시그먼트를 받으면 ACK 플래그를 보낸다. 서버는 해당 데이터를 받았다는 ACK 플래그를 받지 못하면 시그먼트를 다시 보낸다.
4 way handshaking
클라이언트가 서버로 연결을 종료하겠다는 FIN 플래그를 전송하면 서버는 ACK 플래그를 보낸 후, FIN 플래그를 보낸다. FIN 플래그를 클라이언트가 받으면 이를 확인했다는 ACK플래그를 보내고 연결을 종료한다.
- TIME_WAIT : 서버가 FIN 플래그를 보내기 전에 보냈던 데이터들이 FIN보다 늦게 도착할 수 있다. 해당 패킷들의 소실을 방지하기 위해서 클라이언트 서버는 FIN 플래그를 받고 바로 연결을 끊지 않고 일정시간동안 연결을 유지한다. 이 시간을 TIME_WAIT라고 한다.
TCP 단점
TCP는 연결지향 프로토콜이다. 데이터 전송 전에 클라이언트와 서버 간에 연결을 설정하고, 데이터를 전송할 때마다 이 연결을 유지한다. 또 패킷 손실 등의 문제를 감지하고, 이를 해결하기 위한 재전송과 같은 기능을 제공한다. 이러한 TCP의 특성은 아주 빠른 통신이 필요한 경우 단점이 될 수 있다.(연결 설정 과정과 패킷 분할 등으로 인해 오버헤드가 발생. 실시간 데이터 전송에는 적합하지 않다)
이 부분을 보완하기 위해 UDP 프로토콜이라는 선택지가 있다.
UDP 프로토콜
- UDP는 비연결형 프로토콜이다.
- TCP와는 달리, 클라이언트와 서버 간의 연결 설정 과정 없이 데이터를 직접 전송한다.(단방향)
- 데이터를 스트림으로 전송 (전송된 데이터가 일정 크기 이상이 되면 어플리케이션단에서 데이터를 분할하는 과정을 넣긴 해야함)
- TCP의 혼잡제어, 흐름제어 등의 과정 없이 (체크섬에서) 에러만 검출해 준다.(전송되는 데이터의 무결성과 도착 순서를 보장할 수는 없다.)
- 스트리밍 비디오, 실시간 멀티미디어 데이터 전송 등 실시간 데이터 전송,게임 서버에서의 플레이어 위치 업데이트 등 빠른 데이터 전송이 필요한 경우에 적합. (빠른 속도를 요구하고 신뢰성이 중요하지 않은 경우)
-> TCP보다 신뢰성이 떨어지지만 전송속도는 일반적으로 빠르다.
+추가 ) Keep Alive
중간에 하위계층단에서 연결이 끊어지게 되는 경우(네트워크 충격, ex. LAN선을 뽑는 경우, 지하철 이동등으로 인해 기지국을 갈아타는 경우) 이와 관계없이 tcp 연결은 일정 시간(rfc 표준에는 굉장히 김.(시간단위). 그러나 보통 75초안에 끊김. 게임서버 같은 경우에는 더 짧아야함.)동안(논리적으로) 유지 된다.
=> Keep Alive을 통해 tcp 연결이 유지되고 있는지 지속적으로 확인을 하게됨.-> keep alive설정 주기로 keep-alive 패킷을 보내 응답이 오면 연결을 더 유지한다.
참고
http://www.ktword.co.kr/test/view/view.php?m_temp1=1889
https://www.ibm.com/docs/ko/ssw_aix_71/network/tcpip_protocols.html
https://d2.naver.com/helloworld/47667
