[NetWork] TCP/IP 4계층 및 TCP Header 구조

TCP/IP 4계층

데이터 전송과 캡슐화

TCP/IP에서 데이터 전송시 데이터는 상위 계층에서 하위 계층으로 이동하고 계층 이동마다 필요한 정보(헤더)가 추가되며 이를 캡슐화 라고 한다.

 

데이터 수신과 역캡슐화

데이터는 하위 계층에서 상위계층으로 이동하고 계층이동 마다 추가된 헤더를 읽고 해당 헤더에 따라 처리를 하며 헤더를 제거하고 이를 역캡슐화 라고 한다.

 

계층구조

4계층 - 응용프로그램 계층

• 역할 : 사용자와 소프트웨어간 소통을 담당하는 계층이다.
• 데이터 단위 : Data
• 전송 주소 : 없음.
• 프로토콜 : HTTP, HTTPS, DNS, Telnet, 파일전송, 이메일 등
• 장비 : 없음

3계층 - 전송 계층

• 역할 : 호스트간 자료 송수신 및 통신간 신뢰되는 데이터를 전송하는 보장 계층이다.
  • 네트워크와 인터넷 계층을 통해 데이터가 목적지에 정상적으로 도착했다면 포트번호를 사용해 데이터를 목적지 기기내 적절한 에플리케이션으로 전달한다.
• 데이터 단위 : Segment(발신, 수신, 포트주소, 오류검출코드)
• 전송주소 : Port
• 프로토콜 : TCP, UDP
• 장비 : 게이트웨이

2계층 - 인터넷 계층

• 역할 : 패킷을 최종 목적지까지 전달하는 계층이다.(연결성제공), 데이터 전송을 위한 주소지정 및 경로저장
• 데이터 단위 : packet
• 전송주소 : IP
• 프로토콜 - IP, ARP, RARP 등이 사용
  • ARP - IP 주소를 MAC 주소로 변환해주기위해사용(목적지 호스트 IP는 알지만 MAC주소(물리주소)를 모를경우)
  • RARP - MAC주소를 IP주소로 변환해주기 위해 사용(목적지 호스트 MAC은 알지만 IP주소를 모를경우사용)
• 장비 : 라우터

1계층 - 네트워크 액세스 계층

• 데이터를 전기신호로 변환하고 물리주소(MAC)을 사용해 기기로 데이터를 전달한다.
• 데이터 단위 : Frame
• 전송주소 : Mac
• 프로토콜 : Ethernet, PPP
• 장비 : 브리지, 스위치

 

 

---

TCP Header 구조

TCP헤더는 기본적으로 20바이트이지만 옵션 필드에 가변길이를 추가할 수 있으므로 헤더는 유동으로 바뀐다.

 

1. 송신처 포트 번호

• 16 bit
• 이 패킷을 송신한 측의 프로그램의 포트 번호
• unsigned short로 65535까지

2. 수신처 포트 번호

• 16 bit
• 이 패킷을 받는 상대 프로그램의 포트 번호

3. 시퀀스 번호 (송신 데이터의 일련 번호)

• 32 bit
• 이 패킷의 맨 앞 위치의 데이터가 송신 데이터의 몇 번째 바이트에 해당하는지를 송신측에서 수신측에 전달하기 위한 것.
• 보낼 때의 넘버. 바이트단위로 카운팅.

4. ACK 번호 (수신 데이터의 일련 번호)

• 32 bit
• 데이터가 몇 바이트까지 수신측에 도착했는지를 수신측에서 송신측에 전달하기 위해 사용
• 상대방이 나에게 되돌려주는 번호다. 1000짜리를 내가 보내면 상대방이 1000을 아크로 돌려보내준다. 그래서 이게 헤더에 들어있는 것. 보내는 사람은 ack가 와야지만 보낸 것을 확인할 수 있다.

5. 데이터 오프셋 

• 4 bit
• 데이터 부분이 어디부터 시작하는지를 나타낸다. 헤더의 길이를 나타낸다고 생각하면 됨.
• tcp가 유동길이라 헤더의 길이를 계속 알려줌.

6. 컨트롤 비트

• 6 bit
• 이 필드의 각 비트가 각각 통신 제어상의 의미를 가진다.
  • URG : 긴급 포인터의 필드가 유효하다는 것을 나타냄
  • ACK : 수신 데이터의 일련번호 필드가 유효하다는 것을 나타낸다. 보통 데이터가 올바르게 수신측에 도착한 것을 의미
  • PSH : flush 동작에 의해 송신된 데이터임을 나타낸다
  • RST : 접속을 강제로 종료하고 이상 종료시에 사용한다
  • SYN : 송신측과 수신측에서 일련번호를 서로 확인한다. 이것으로 접속  동작을 나타낸다.
  • FIN : 연결 끊기를 나타낸다.

7. 윈도우

• 16 bit
• 수신측에서 송신측에 윈도우 사이즈를 통지하기 위해 사용한다. (윈도우 사이즈 : 소신 확인을 기다리지 않고 묶어서 송신할 수 있는 데이터 양)
• L2와 L3는 상대방을 배려하지 않는다. MAC Address, ip만 담아서 막 던진다. 상대가 있는지 없는지도 모르고 일단 담아서 단진다. 그런데 tcp에는 안전한 100%의 전송을 보장해야 한다. send 했으면 100% 간다. 데이터가 깨지는 것도 버퍼를 잘못 보낸 것. L2 L3는 연결의 개념이 아니다. 근데 여기부터는 연결의 개념이 있다. 서로 상호간의 연결, 정보를 저장한다.
• TCP는 데이터를 보내고자 할 때 송신버퍼에 데이터를 넣어준다. send 했다고 보내지는게 아니라, 송신 버퍼에 copy 하는 것. 보냈는지 안 보냈는지, 갔는지 안 갔는지 우리는 모른다. 10분뒤에 갈 수도, 안 갈 수도 있다. 우리는 단지 송신 버퍼에 copy 했는지만 알 수 있다. 상대방이 받을 수 있는 상태인지 확인을 해야 보낸다. 
• 수신측에서는? 상대방에게 데이터가 오면 수신 버퍼에 쌓인다. recv는 데이터를 실제로 받는 것이 아니다. 데이터를 받은건 이미 수신버퍼에 있다. recv는 수신버퍼에서 copy 해오는 것. 내부적으로 어딘가 받아두고 있는 게 수신버퍼다. 실질적으로 보내고 받는 건 TCP 커널이 한다. 우린 copy만 하고 기다리는 것. TCP 소켓을 생성하면 송수신 버퍼를 설정해준다. 윈10부터 64kb로 용량이 커졌다. 옵션으로 조절 가능
• 여기서 말하는 '윈도우 사이즈' 란, 내가 안전하게 받을 수 있는 사이즈를 의미한다. 우리 어플리케이션에서 아무런 recv 하지 않고 아무런 동작 하지 않아도 수신버퍼가 1000바이트라면 1000바이트까지는 받을 수 있다.
• 우리는 TCP 구조에서 상대방의 윈도우 사이즈를 항상 알아야 한다. 그래서 서로 계속 주고 받는다. 데이터를 쏠 때도, ACK를 보낼 때도 항상 수신 버퍼에 공간이 얼마 남았다고 알려준다.
• 만약 수신 버퍼가 다 차거나 1바이트 남았다면?
  • 그러면 윈도우 사이즈가 1로 갈 거다.
  • 윈도우 사이즈는 실시간으로 반영해야 하니까 계속 담긴다. 
  • 그리고 ACK를 보낸다는 것도 우리가 보내는게 아니라 TCP스택 차원에서 데이터를 받으면 자동으로 ACK를 쏘게 되어있다. 세팅하는게 아니다. 그리고 이럴때마다 윈도우 사이즈가 담긴다는 것.
  • 그런데 이렇게 윈도우 사이즈가 1로 갔으면, 1바이트 이상을 안 보낸다. 버퍼가 없기 때문에. 보내야 할 데이터가 몇 백 바이트가 쌓여도 최대 1바이트밖에 안 보낸다. 
  • 1바이트가 남았는데 읽어들여서 여유공간이 더 생기면 바로 알려준다.
• 제로 윈도우 란?
  • 제로 윈도우라는 상황은 특수한 상황이다. 
  • 윈도우 사이즈가 0이 된 상황에서는 계속 보낸다. '나 0이니까 보내지 마'
  • packet capture를 해보면 상대방이 계속 0이라고 알려주고 있다. 
  • 그 외에는 통신하지 않는다 
    • TCP는 아무 이유 없이 체크하는 게 존재하지 않는다. 기본적으로 연락이 없으면 통신하지 않는다.
• 서버가 느리면 연결이 끊길까?
  • 아니다. 
  • 송신을 못하고 송신 버퍼가 꽉 차면, send 에서 에러가 난다. 
  • 그래도 보내지지 않아지는거지, 연결이 끊기는 게 아니다.

8. 체크썸

• 16 bit
• 오류 유무를 검사하기 위한 것.
• 해쉬랑 같다. 헤더에 들어있는 체크썸과 내가 갖고 있는 체크썸이 같아야 한다.
• 데이터가 바뀌거나 노이즈로 변조가 된다면, 체크썸 결과가 다르게 나올 것이다. 그래서 체크썸이 있다.
• 여기 TCP헤더에는 있지만, IP헤더에 있는 체크썸은 사라졌다. L2에서 해주기 때문에 또 할 필요가 없다.

9. 긴급 포인터

• 16 bit
• 긴급하게 처리해야 할 데이터의 위치를 나타낸다
• 위에 컨트롤 비트의 URG와 세트로 작동한다. 이건 비유하자면 고속도로의 갓길이다. 
• OOB메세지 (Out of Band)를 활성화 시키면 일반 데이터 전송과 별도로 간다. 

 

참조 - https://velog.io/@jehjong/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%B8%ED%84%B0%EB%B7%B0-TCPIP-4%EA%B3%84%EC%B8%B5

https://popcorntree.tistory.com/94