OSI 7계층 - 전송 계층

프로토콜에 있어 TCP/IP가 표준은 아닐지언정 약간 생태계 독점을 하고 있는 느낌인가 본데 왜..............TCP/IP 4계층을 OSI 7계층과 비교하는 게 금기시되는 일인지 모르겠다

OSI 생태계에 harm을 끼친다는데 아무래도 ISO에서 표준을 지정했는데 TCP/IP가 또 레이어 빚어온 그런 분위기인가? 싶다.

 

TCP/IP 레이어도 짚고 넘어가면 좋겠지만 그걸 OSI 7계층과 병행하기에는 문서상으로 너무 어그러질 것 같다는 생각이 들어서 일단은 OSI 7계층을 짚고 나중에 천천히 톺아보는 것이 좋을 것 같다....그리고 지엽적인 문제를 너무 자주 짚어서 뭐 하나 배우는데 시간이 너무 많이 걸린다...ㅠㅠ

NAVER D2

일단 IP도 체크섬 같은 걸로 받은 데이터가 옳은지 아닌지를 검증하기는 하는데 틀린 걸 해결할 방법이 없다. IP가 신뢰성이 부족하다고 말하는 이유도 여기에 있다.

그래서 TCP로 이 친구의 부족한 신뢰성을 보완하려고 하는 것이다...

TCP의 특징은 다음과 같다.

1. 연결 지향 - 서로 통신이 가능한 상태인지를 확인하고, 연결하고-끊는다. 3 way handshake, 4 way handshake.
2. 신뢰성 - 받지 못한 데이터를 재전송하라고 요청할 수 있기 때문에 기존의 IP가 가지고 있던 부족한 신뢰성을 채움.
3. 이 과정 덕분에 좀 느림.

• Source Port : 보낼 때의 port 번호. 16bit(65535)의 크기 때문에 사실상 이 친구가 포트 번호에 제한을 둔 셈이다.
• Destination Port : 받는 곳의 port 번호. 같은 크기...
• Sequence Number : tcp는 보내는 패킷의 순서를 기입. 또한 이 값을 기준으로 순서를 보장. 32bit, unsigned int32의 최대값은 4,294,967,295....대량의 데이터 패킷의 순서를 기입할 수 있는...것 같다.
• ACK Number : 일종의 OK 사인으로 보내지는 패킷. 이걸 ACK(Acknowledgment)이라고 하는데 그거에 대한 번호다.
• Offset : 이것도 ip 처럼 1이 4byte인데 header 크기값이다. tcp도 ip와 똑같이 헤더의 최소크기는 20byte이다. 그래서 여기에 적히는 최소값은 5이고 최대값은 60이 된다.
• Reserved : 여기의 3bit는 어디에 쓸지 아직 정해지지 않은 일종의 예비 공간이다. 그래서 여기의 값은 필요 없다. 위의 그림은 4bit가 표시되어있는데 나머지 1bit는 NS 필드로 일단 알아둘 필요는 없다. pass
• TCP Flags : 논리적인 TCP 연결 회선 제어와 데이터 관리를 위해 사용. 근데 왜 8개 있는 애가 있고 6개 있는 애가 있는거지?
  • URG(Urgent) : 긴급 데이터 플래그 / 긴급 데이터의 우선순위를 높여 긴급하게 전달. 1로 선정하면 순서와 관계없이 먼저 전달됨.
  • ACK(Acknowledgement) : 응답 플래그 / 송신측으로부터 패킷을 잘 받았다는 걸 알려주는 플래그. 1일 땐 확인번호 유효, 0일 땐 확인번호 미유효. 연결이 된 이후로는 모든 세그먼트(TCP에서 전송하는 패킷)에는 항상 이 비트가 1로 세팅됨. 0일 경우에는 ACK Number 필드는 그대로 무시됨. ← 근데 이럴거면 저렇게 큰 사이즈로 ACK number를 헤더로 지정할 이유가 있었나?
  • PSH(Push) : 넣기 플래그 / 버퍼가 채워지기를 기다리지 않고 받는 즉시 전달. 수신받는 즉시 버퍼링된 데이터를 응용 프로그램에 전달한다는데 실시간으로 전달할 걸 요청을 하는건가? 일반적으로 버퍼에 채울 때까지 기다리는 이유가 있는건가? 이게 신뢰성 면에서 영향을 주기 때문인가? 아니면 약간 UDP 같이 신뢰성이 조금 떨어지더라도 속도 면에서 이점을 얻어야 하기 때문인가?
  • RST(Reset) : 연결 재설정 플래그 / 비정상적인 세션을 끊기 위해 연결을 재설정하는 과정. 연결이 이미 된 상태에서 플래그를 1로 설정하면 그대로 연결이 끊기고 LISTEN 상태(이건 3way handshake 참고)로 들어가게 된다.
  • SYN(Synchronization) : 연결 요청 플래그 / 통신 시작 시 세션을 연결하기 위한 플래그.

  . 연결요청  : SYN=1,ACK=0   (SYN 세그먼트)
  . 연결허락  : SYN=1,ACK=1   (SYN+ACK 세그먼트)
  . 연결설정  : ACK=1         (ACK 세그먼트)
  

  • FIN(Finish) : 연결 종료 플래그 / 더 이상 전송할 데이터가 없으며 세션 연결을 종료하겠다는 선언을 보내는 플래그.

   . 종결요청 : FIN=1           (FIN 세그먼트)
   . 종결응답 : FIN=1,ACK=1    (FIN+ACK 세그먼트)
  

• Window Size : 수신측의 버퍼 크기(Receive Window Size)에 대한 이야기이며 TCP의 흐름 제어와 연관된 내용이다. 버퍼 쪽에서 받을 수 있는 여유 용량을 지속적으로 통보한다.

..TCP 연결은 양방향이므로, 매TCP 세그먼트를 보낼시 마다,
.. 이 필드에 자신의 수신버퍼 용량 값을 채워 보내게 됨 (지속적인 현행화)
. 결국, 양방향 각각의 수신측에 의해 능동적으로 흐름제어를 수행하게 됨. <- 이게 뭐지

• Checksum : IP 헤더에 나온 그거...똑같이 전체를 다 더하고 1의 보수를 취하고 기입한 다음 수신부에서도 똑같은 값을 받았는지를 확인하는...
• Urgent Pointer : TCP에서는 긴급하게 더 우선적으로 전달하기 위한 패킷을 알려줌. ← 이건 플래그랑 무슨 차이지?

1. 여기서 순서 번호라는 개념이 나오는데 이게 Sequence Number가 맞겠지?? 승인번호라는 건 ACK을 말하는 걸테고
2. 순서 번호는 왜 랜덤한 수로 정해서 보내는 거지?
3. 일단 랜덤한 순서 번호를 보내고 응답으로 ACK=1이 올 때까지 대기하다가 그 다음엔 ACK=1만 보내주면 연결 설정이 되고 서버측에서 Listen 상태가 되는듯.
4. 만약 RST을 보내면 4way handshake를 기반으로 끊어지는 건가?

1. FIN을 보내면 어플리케이션이 종료되고
2. 서버 측에서 응답했음을 알리고
3. 클라이언트 측에서는 FIN 응답이 올 때까지 계속 기다리다가
4. 서버가 종료되면 FIN을 보내주고
5. 클라이언트에서 ACK을 보내주면 서버는 종료되고
6. 클라이언트는 그냥 대기하다가 자동으로 종료되는건가? 지정한 수명 내지는 default 시간만큼을 기다리고 종료된다. 이 딜레이 때문에 connection pool 등을 사용하지 않고 connect-disconnect 방식으로 DB나 cache와 같은 dependency를 연결할 때 tcp connection으로 메모리가 전체 할당되어 서버가 빠그라지는 케이스가 생길 수도 있다고 한당