지니의 따듯한 공간

TCP / IP 본문

카테고리 없음

TCP / IP

Jineer 2021. 1. 4. 15:37

TCP / IP 프로토콜 모음

 - 프로세스간 통신 개설(포트 번호 이용)

 - 전송 단계에서 흐름 제어 메커니즘 제공
   (슬라이딩 윈도우 프로토콜 이용)

 - 전송 단계에서 오류 제어 메커니즘 제공
   (응답 패킷, 시간-초과, 재전송 방식 이용)

 - 연결 지향의 신뢰성 있는 프로토콜

 

※ 프로세스간 통신

TCP  IP

 - IP는 컴퓨터 레벨에서의 통신의 기능을 담당

 - IP는 메시지를 목적지 컴퓨터까지만 전송

 - TCP는 응용 프로그램으로 메시지를 전송하는 역할을 담당 (port 번호를 이용)

 

※ 클라이언트 - 서버간 통신에 필요한사항

- 로컬 호스트 - 원격 호스트 (IP주소)

 

- 로컬 클라이언트  프로그램 - 원격 서버 프로그램  (포트번호)

 

 

포트 주소

 

 

TCP에서 사용되는 잘-알려진 포트

DNS는 기본적으로 UDP를 이용 / 그러나 TCP를 사용할 때도 있다. 

                                           데이터가 일정 규격을 넘었을 때 TCP 사용

 

 소켓 주소

- IP 주소와 포트 번호의 조합

- 종단간 연결 설정에 사용

- 클라이언트와 서버 소켓 주소 필요

- IP 헤더(IP 주소)와 TCP 헤더(포트 번호)에 들어있음

 

※ TCP

-프로세스 대 프로세스 통신

- 스트림 배달 서비스

- 연결지향 서비스

 - 신뢰성 서비스

 

※ 스트림 배달 서비스

- TCP는 스트림 기반 프로토콜 /버퍼에 쌓으면 흐름처럼 흘러간다 (OS에서 알아서 보내준다)

- 바이트 스트림 형태로 데이터 송수신

- 두 개의 프로세스가 가상의 튜브로 연결

- 송신 프로세스는 바이트 스트림 생성(쓰기), 수신 프로세스는 바이트 스트림 소비(읽기)

 

 - 송신 TCP

   송신 응용 프로그램으로부터 문자 스트림 수신(송신 버퍼 이용)

   적절한 크기인 세그먼트를 만들어 네트워크를 통하여 전송

- 수신 TCP

  세그먼트를 수신(수신 버퍼 이용)

데이터를 추출하여 문자 스트림으로 수신 응용 프로그램에 전달

 

 !! UTP케이블을 보면 4개가 수신 4개가 송신 / 네트워크 선로가 따로구성 되어있다.

 

송신 버퍼와 수신 버퍼

세그먼트 -> 패킷 -> 프레그멘테이션(단편화) -> 

 

 

세그먼트

- 일련의 바이트를 세그먼트라는 패킷으로 그룹화 IP계층에 전달

 

 전이중 서비스

- 동시에 양방향 전송

- 송신 데이터와 수신 데이터에 대한 확인 응답을 
함께 보내는 피기백킹(piggybacking)

 

 연결-지향 서비스

- TCP는 연결지향 프로토콜

- 물리적 연결이 아닌 가상의 연결

- 요청→승인 → 데이터 교환 → 해제 순으로 진행

 

 신뢰성 서비스

- 확인응답 메커니즘 이용

 

데이터는 모두 라우터를 통해서 간다. (외부 네트워크와의 통신)

 

  바이트 번호

- 모든 데이터 바이트에 번호 부여

 

  순서번호 (시퀀스 번호 4byte)

- 세그먼트에 있는 첫 번째 바이트에 순서번호 할당

 

  확인응답 번호 ( 애크널러지 번호 4byte) 

- 자신이 수신하기를 기대하는 다음 바이트 번호

   (데이터 잘 받았고, 그다음에 데이터 이 번호부터 주면 된다.) 

 

※ 흐름제어

 목적지로부터 확인응답 수신 전에 발신지가 전송할 수 있는 데이터 양을 정의

 

 슬라이딩 윈도우 프로토콜

- 호스트는 각 연결마다 하나의 윈도우 이용

- 윈도우는 다른 호스트로부터 확인응답 없이 한 호스트가 전송할 수 있는 버퍼의 범위를 나타냄

- 윈도우는 데이터가 전송되고 확인응답이 수신될 때마다 버퍼의 범위가 미끄러지듯이(sliding) 이동

- 송신 측 버퍼

 

 

송신자가 수신응답을 받지않고 보낼 수 있는 최대 크기 : 윈도우 사이즈

 

800정도 보내고있었는데 응답번호가 500이왔다. 

그럼 500부터 다시 보낸다.

// 응답번호 : 내가 잘 받았으니 다음꺼 보내라.  

 

송신측과 수신측의 버퍼크기 (즉, 전송 속도 차이가 날 때)

버퍼가 꽉 찾을때, 윈도우 사이즈를 줄여서 응답을 보낸다.

그럼 송신자도 줄이는 방식.

 

수신 윈도우

- 수신 TCP는 얼마나 많은 바이트를 수신할 수 있는가?

- 수신 버퍼의 전체 크기가 N이고 M부분이 이미 차 있으면

- N - M개의 추가 바이트만이 수신될 수 있음

- 이 값을 수신 윈도우라고 함

    Ex) N=13이고  M=6이면, 수신 윈도우의 값은 7이 됨

- 수신 윈도우

수신 윈도우

 

 

 송신 윈도우

- 송신 측에서 수신 윈도우보다 작거나 같은 크기를 갖는 윈도우  (송신 윈도우)를 만들어 흐름제어를 할 수 있음

- 송신 윈도우는 전송되었지만 확인응답되지 않은 바이트와 전송될 수 있는 바이트를 포함

- 수신 측으로부터 새로운 소식이 올 때까지는 전송되지 못함

- 송신 버퍼와 송신 윈도우

송신 윈도우

 

송신 윈도우의 이동

 

 

 

 

 송신 윈도우를 닫음

- 수신 버퍼가 모두 다 차게되면 수신 윈도우의 크기는 0이 됨

- 송신측에 전달되면 송신측은 윈도우를 닫음

- 송신측은 수신측에서 0이 아닌 윈도우 값을 알려주기 전까지는 더 이상의 바이트를 전송할 수 없음

 

TCP 세그먼트 형식 

 ※ 발신지 포트 번호(source port address)

 - 전송 호스트 응용 프로그램의 포트 번호

 목적지 포트 번호(destination port address)

 - 수신 호스트 응용 프로그램의 포트 번호

 

 순서번호(Sequence Number) (4 byte)

- TCP 데이터 전송 순서를 나타냄

     ISN(Initial Sequence Number) : 초기 순서 번호

     난수 발생기를 이용하여 ISN을 만들어 사용

 

 확인응답 번호(Acknowledgement Number) (4 byte)

 - 다음에 받아야 하는 순서번호를 나타냄

      송신자가 보낸 순서번호 x를 성공적으로 수신

      수신자는 송신자에게 확인번호 x+1로 송신

Ÿ제어 6비트 중 ACK비트가 설정되어 있을 때 유효

<헤더 길이(Header Length) (4 bit)

ÜTCP 헤더의 길이를 4 byte 워드 개수로 정의

헤더길이 : 20 ~ 60 byte(필드 값은 5 ~ 15)

 

 

 어리석은 윈도우 신드롬

- 전송/수신 응용 프로그램이 데이터를 천천히 생성하거나 천천히 처리할 때 발생

- 예 : 1 바이트 데이터 + 20 바이트 TCP 헤더 + 20 바이트 IP 헤더

 

 송신 측에서 발생하는 신드롬

- 가능한 한 바이트 데이터를 전송하지 못하게 함

- 데이터를 취합하여 큰 블록 데이터로 만들어 전송  // 윈도우 1을 받더라도 바로 보내지말고.. 어느정도기다렸다가 ㄱ

- Nagle 알고리즘 적용

        송신 TCP에서 실행하는 알고리즘

 

/* 수신자의 컴퓨터가 느릴 경우, 하나를 처리하면윈도우가 1이된다.

수신쪽의 버퍼가 꽉 찼다 . -> 윈도우 0을보낸다.

송신측은 0이 아닌 값이 올때까지 기다린다.

윈도우 1을 보낸다.. 그럼 송신측에는

tcp헤더20 + 데이터1 + IP헤더20 = 총 41 바이트 패킷이 온다. 그중에서 1만뽑아서 ..

네트워크의 효율이 떨어진다.. 오버헤드값만 엄청 보내고 실제로 데이터는 얼마 안된다.. */

 

 

 Nagle 알고리즘

1.송신 TCP는 응용 프로그램으로부터 수신한 첫 데이터를 세그먼트로 만들어 전송한다.

2.첫 번째 세그먼트를 전송한 후 송신 TCP는 수신 TCP로부터 확인 응답을 수신하거나 최대 크기의 세그먼트를 구성할 정도로 데이터가 출력버퍼에 저장되면 세그먼트를 전송한다.

3.2번째 단계를 계속 반복한다.

 

 수신 측에서 발생하는 신드롬

- 어리석은 윈도우 신드롬이 발생하는 상황에서 한 바이트 수신 처리 후에 윈도우 크기를 통보하게 되는 경우

 

 Clark 해결 방법

- 충분한 공간이 생기거나 적어도 버퍼가 반 이상 비어있을 때까지 윈도우 크기를 0 으로 통일

 

 확인응답 지연

- 수신 버퍼가 충분한 공간이 생길 때까지 확인응답 보류

 

 오류 발견과 정정

- 오류 발견 도구 : 검사합, 확인응답, 시간-초과

- 세그먼트의 검사합 필드 이용 훼손 여부 확인

- 수신을 송신측에 알려주는 확인응답 이용

- 시간-초과 전까지 확인응답 되지 않으면 훼손 또는 손실 간주

- 오류 정정 : 시간-초과 카운터 이용 - 재전송

 

 

 

※ TCP 타이머

 

 

단일 스레드  /  단일 프로세서

하나가 끝날때 까지 기다린다. 

 

 

멀티 프로세서 / 다중 스레드

채팅 프로그램 짤 때.. 등등 하나의 프로그램당 하나의 프로세서가 맡아서 처리

 

   재전송 타이머

- 손실 또는 손상되어 버려지는 세그먼트를 처리

- 재전송 시간은 한 세그먼트를 전송하고 확인응답을 기다리는 시간으로 정의

- TCP는 세그먼트를 전송 후, 해당 세그먼트를 위한 재전송 타이머를 구동

- 다음과 같은 두 가지 상황이 일어날 수 있음

          1. 타이머가 끝나기 전에 특정한 세그먼트에 대한 확인응답이 수신되면, 그 타이머는 소멸

          2. 만일 응답이 수신되기 전에 타이머가 종료되면 해당 세그먼트는 재전송되고 타이머는 초기화

 

    재전송 시간의 계산

- 모든 연결에 일률적으로 적용할 수 없음

- 재전송 시간-초과는 왕복(round-trip) 시간을 기반 동적으로 계산

- 재전송 시간 = 2 * RTT(Round-Trip Time)

 

    RTT 계산

- 두 가지 방법

    1. 타임스탬프 옵션을 사용

    2. TCP가 세그먼트를 전송하고, 타이머를 구동하여 확인응답을 기다리는 방법

- RTT 계산 공식

  𝑅𝑇𝑇=𝑎  이전 𝑅𝑇𝑇 + (1 −a) ∗ 현재 𝑅𝑇𝑇

 

   Karn 알고리즘

- 전송된 세그먼트에 대해 확인 응답되지 않아 재전송된 경우

- 이전 세그먼트에 대한 확인응답인지 재전송에 대한 확인응답인지 여부 판단이 애매하다

- RTT 값은 재전송 없이 확인응답 수신 전까지 변동이 없음

 

  영속 타이머(persistence timer)

- 윈도우 크기가 0 인 경우를 처리하기 위한 타이머

- 수신 TCP가 윈도우 크기 0 을 통보했는데, 송신 TCP가 이에 대한 확인응답을 보냈지만 수신 TCP가 이를 수신하지 못함

- 양쪽 TCP가 서로 기다리는 교착상태(deadlock) 해결

     // 교착 상태를 해결하기 위해 타이머를 하나 더 만든 것

 

 

  킵얼라이브 (Keepalive) 타이머

-  TCP 간에 설정된 연결이 오랫동안 휴지(idle) 상태에 있는 것을 방지하기 위한 타이머

- 시간-종료 : 2 시간

- 2 시간이 지나도록 세그먼트를 수신하지 못하면 75초 간격으로 10 개의 프루브(probe) 전송

- 응답이 없으면 다운으로 간주하고 연결 종료

 

휴지(idel)상태 : 서로 데이터를 주고 받지 못하는 상태

 

  시간-대기 타이머 (Time-waited timer)

- 연결 종료 동안에 사용

 

 

 

 

 

 

 

 ※ 순서번호(Sequence Number) (4 byte)

- TCP 데이터 전송 순서를 나타냄

       - ISN(Initial Sequence Number) : 초기 순서 번호

       - 난수 발생기를 이용하여 ISN을 만들어 사용

 

 확인응답 번호(Acknowledgement Number) (4 byte)

- 다음에 받아야 하는 순서번호를 나타냄

       - 송신자가 보낸 순서번호 x를 성공적으로 수신

       - 수신자는 송신자에게 확인번호 x+1로 송신

Ÿ제어 6비트 중 ACK비트가 설정되어 있을 때 유효

 

 헤더 길이(Header Length) (4 bit)

- TCP 헤더의 길이를 4 byte 워드 개수로 정의 

    - 헤더길이 : 20 ~ 60 byte(필드 값은 5 ~ 15)

 

※ 예약(Reserved) (6 bit)

  - 사용되지 않는 필드, 모두 0으로 표기

※ 제어(Control) (6 bit)

- URG - 긴급 플래그

    :긴급 포인터(Urgent Pointer) 필드가 유효하며 이를 사용해야 함을 표시

- ACK - 응답확인(Acknowledgement) 플래그

    : 응답확인 필드가 유효하며 세그먼트 응답확인을 운반하고 있음을 알림

- PSH – Push 플래그

    : 송신 시스템은 데이터를 즉시 전송하고 버퍼를 비움

- RST – Reset 플래그

    : RST비트가 설정된 세그먼트를 수신하면 수신측 호스트는 연결을 절단함

- SYN – 동기화(Synchronize) 플래그

   : 커넥션을 확립하는 동안에만 설정

   : 순서번호 필드에 있는 번호가 유효하여 ISN으로 취급되어야 함을 알림

- FIN – 종료(Final) 플래그

  : 송신측 호스트에 데이터가 없으며 커넥션을 종료함을 알림

 

연결설정과 관련 없는 패킷은? -> syn나 ack가 체킹 안되어있는 것 골라 낼 수 있어야한다.

 

Comments