전송 계층의 역할 (응용계층 아래, 네트워크 계층 위) - 응용 계층의 어플리케이션 프로세스 식별 : 포트!!!!!!! - 네트워크 계층의 신뢰성/연결성 확립 : 네트워크계층의 IP한계 해결
포트 - 포트 번호는 16비트로 표현 가능(65536개) - 포트 범위 : 0번부터 65535번까지 - 포트의 종류 : 범위에 따라서 나뉨
- 잘 알려진 포트( 웰 노운 포트, 시스템 포트 ) : 널리 알려진, 유명한 포트 - 업체막론하고 정말 많이 사용하고 식별을 위해 사용됨. - 등록된 포트 : 잘 알려진 포트에 비해서는 덜 범용적이지만 흔히 사용되는 애플리케이션 - 특정기업, 특정 어플리케이션을 위해서 할당이 된 경우가 많음
- 서버는 일반적으로 잘 알려진 포트와 등록된 포트로 동작 -HTTP 서버, 웹서버, 무슨 무슨 서버 - 클라이언트는 일반적으로 동적 포트로 동작
네트워크 계층에서의 NAT : 공인 IP 주소와 사설 IP 주소 간의 변환 기능 - 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유 가능 <- 포트를 활용!!!!!! - IP주소를 변경은 라우터를 이용하고NAT변환이라는 특별한 테이블을 이용하는데, 같은 공인IP를 이용하되 포트번호만 다르게 하면 공유가 가능! - IP 주소 부족 문제 해결
포트 확인 방법 - 윈도우 운영체제에서 리소스 모니터에서 확인이 가능함! - 리눅스에서는 netstat 명령어를 통해서 확인
TCP 와 UDP 전송계층에서 가장 중요한 프로토콜
MSS: TCP 세그먼트로 보낼 수 있는 최대 크기
- 페이로드의 크기만 따짐
TCP 세그먼트 - 구조
- 출발지 포트 : 어플리케이션 프로세스를 식별할 수 있는 고유번호인 port!로 출발지 명시 - 목적지 포트: port!로 목적지 지정
- 순서 번호 (TCP에서 가장 중요) - 송수신되는 세그먼트 데이터 첫 바이트에 부여되는 번호 - MSS가 정해져있어서 전송데이터를 세그먼트로 나누어서 보냄 : 가장 첫 세그먼트에 숫자를 붙여줌 (초기 순서번호를 100으로 하고 500바이트 단위면, 순서번호는 100/600/1100/...) - 세그먼트를 순서대로, 누락없이 보내기 위해서 번호를 붙이는 걔념
- 확인 응답 번호 (TCP에서 가장 중요) - 순서 번호에 대한 응답 - 다음으로 수신받길 기대하는 바이트 번호 - 수신번호가 100인 세그먼트를 보냄 -> 잘 받은 후에, 다음에 응답받기를 기대받는 것은 101(확인응답번호) - 호스트가 100번을 잘 받고, 101번을 받고자하는지 알 수 있음!
- 제어 비트 - ACK: 세그먼트 승인을 나타내는 비트 -SYN: 연결 수립을 위한 비트 : 처음 데이터 송수신을 할 때 쓰임 -FIN: 연결을 끝내기 위한 비트 : 연결지향형 프로토콜이라 사용!! -RST: 연결을 리셋하기 위한 비트
- 윈도우 - 수신지 윈도우 크기. 한 번에 수신 받고자 하는 양 (흐름 제어에서 언급)
UDP
- IP 패킷을 감싸는 껍데기일 뿐, 전송계층에서의 최소한의 기능 - 비연결성/비신뢰성 프로토콜 : 신뢰성X, 연결X - TCP의 재전송/흐름 제어/혼잡 제어 등의 기능 없음
- 체크섬 : 수신된 데이터에 오류가 있는지 없는지 판단하는 필드 - 신뢰성X : 체크섬 필드는 신뢰성과는 관련이 없다 - 받은 데이터에 대해서 오류가 없는 것만 말할 수 있음
- 최근 빠른 성능으로 각광받는 UDP : HTTP/3, NTP, RIP, DNS, DHCP
비교 - 하나 하나 확실히 보내는 TCP - 빠르게 마구 던지는 UDP
TCP에 관하여
TCP 연결 - TCP는 연결형 프로토콜 1. 연결 설정 <- Three-way handshake : TCP가 연결을 수립하는 과정을 이르는 말 Three-way handshake
- 3개의 단계를 거침 : 3 way handshake
- 엑티브 오픈 호스트 : 연결을 시작하는 호스트 - 패시브 오픈 호스트 : 연결 요청을 수락하는 역할, 보통 서버! 여기서는 호스트B
2. 데이터 송수신 3. 연결 종료
- 액티브 클로즈 호스트 : 처음 연결종료를 요청하는 호스트 - 패시브 클로즈 호스트 : 연결종료를 받아드리는 호스트
- 액티브 클로즈 호스트는 마지막 ACK을 보낸 뒤 일정 시간을 기다리고 연결을 종료 - 마지막 ACK 세그먼트의 유실 대비 - 또 다른 연결 과정에서의 패킷 혼선 방지
TCP 상태 - TCP는 연결형 프로토콜 + TCP는 스테이트풀(stateful) 프로토콜 : 스테이트풀 : state 상태! -> 현재 연결 상태를 나타내기 위해 다양한 상태(state) 활용
- TCP의 가능한 상태 목록 -CLOSED : 어떤 연결도 안한 상태 , 아무런 연결이 없는 상태
- 연결 수립 도중 사용되는 상태
엑티브 오픈 호스트 - SYN-SENT : SYN 세그먼트를 보낸 뒤 SYN+ACK 세그먼트 대기 패시브 오픈 호스트 - LISTEN : SYN 세그먼트르 기다리는 상태 (서버 호스트) - SYN-RECEIVED : : SYN+ACK 세그먼트를 보낸 뒤 그에 대한 ACK 대기
- ESTABLISHED : 현재 데이터 송수신이 가능한상태, 연결 되어있는 상태 - Three-way handshake 끝났을 경우, 데이터 송수신 가능
- 연결 해제시 사용되는 상태
액티브 클로즈 호스트 - FIN-WAIT-1 : FIN세그먼트를 보내고 ACK세그먼트를 기다리는 상태 - FIN-WAIT-2 : ACK 세그먼트를 받고,다음 FIN 세그먼트를 받기전까지 기다리는 상태 - TIME-WAIT :TIME_WAIT 상태에서 일정 시간을 기다리고 연결을 종료 패시브 클로즈 호스트 - CLOSE-WAIT :FIN을 받아서 ACK세그먼트를 보내고 다음 FIN 세그먼트를 보내기를 기다리는 상태 - LAST-ACK : 마지막 FIN 세그먼트를 보내고, ACK세그먼트를 기다리는 상태 - CLOSING : (보통 동시에 연결을 종료하려 할 때 발생 - 상대 FIN 세그먼트에 ACK 세그먼트를 보냈지만 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못한 상태
TCP의 재전송 기능
TCP는 신뢰성 프로토콜 - 무엇인가를 확실히 전송했다는 보장을 하기 위해 - 재전송 기반의 오류 제어: 잘못 전송된 경우 재전송 - 흐름 제어 : 받을 수 있을 만큼만 받기 - 혼잡 제어 : 보낼 수 있는 상황에서만 보내기
- 언제 잘못 되었음을 인지할 수 있는지 - 중복된 ACK 세그먼트를 수신했을 때 - 타임아웃(재전송 타이머의 타임아웃)이 발생했을 때
- TCP 오류 제어 - TCP는 재전송 기반의 오류 제어를 수행 - 재전송을 기반으로 잘못된 전송을 바로잡는 것: ARQ (자동 재전송 요구)
ARQ (자동 재전송 요구) - Stop-and-Wait ARQ -가장 단순한 형태 - 제대로 보냈음을 확인하기 전까지는 보내지 않음 : 1번을 받았다는 확인응답 못 받으면 2번을 안 보냄 - 전송하고, 확인하고, 전송하고, 확인하고....를 반복함 - 네트워크 이용 효율이 낮아지는 문제 : 현재 잘 사용하지 않음 -> 이런 문제를 해결하려면? 여러 세그먼트 한 번에 전송 == 파이프라이닝
- Go-Back-N ARQ - 파이프라이닝을 사용하는 방식!!! 오늘날, Selective와 적절하게 섞어서 사용함. - 올바른 세그먼트에 대해서는 확인 응답 보냄 - 올바르지 않은 세그먼트(e.g. N번 세그먼트)가 수신되면 이후(N+1번 이후) 모든 세그먼트 폐기 - 올바르지 않는 세그먼트가 들어가면 그 후 세그먼트도 모두 다시 전송 - 누적 확인 응답 (Cumulative ACK)
- Selective Repeat ARQ - 올바른 세그먼트에 대해서만 확인 응답 보냄 - 각 세그먼트에 대한 확인 응답 - 올바르지 않은 세그먼트만 다시 송신하면 됨!!! - 개별 확인 응답
-빠른 재전송 (fast retransmit) -빠른 재전송이 있는 경우: 재전송 타이머가 만료되지 않아도 중복 세그먼트가 수신되면 재전송 - 문제 발생되어도 빠르게 재송신가능
TCP의 혼잡제어와 흐름제어
TCP는 신뢰성 프로토콜 - 무엇인가를 확실히 전송했다는 보장을 하기 위해 - 재전송 기반의 오류 제어: 잘못 전송된 경우 재전송 - 흐름 제어 : 받을 수 있을 만큼만 받기 - 혼잡 제어 : 보낼 수 있는 상황에서만 보내기
- 파이프라이닝 전송: 송수신시, 받을수 있는 양과 보낼 수 있는 양이 정해져있다. - 버퍼의 크기가 있다.
TCP 흐름 제어 - 송신 버퍼와 수신 버퍼 - 송신 버퍼: 어플리케이션 계층에서 전송할 데이터 임시 저장 - 수신 버퍼: 네트워크 계층에서 수신할 데이터 임시 저장
- 버퍼 오버플로우: 일부 데이터가 처리되지 않을 수 있음 (버퍼넘침!!!) - 송신 호스트가 수신 호스트가 처리할 수 있는 수신 버퍼보다 더 많은 데이터를 전송하는 경우
- 흐름제어 : 오늘날 TCP에서의 흐름 제어 :슬라이딩 윈도우(sliding window) - 송신 호스트가 수신 호스트 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 것 -> 수신호스트가 송신호스트에게 수신량을 알려줘야함 : TCP 헤더에 세그먼트필드에 있는 window필드를 통해서 보내줌
- 윈도우 - 파이프라이닝 가능한 순서번호 범위 - 윈도우 크기: 확인 응답 받지 않고도 한번에 보낼 수 있는 최대 양 - (수신) 윈도우 크기: TCP 헤더를 통해 송신지에게 알려주는 정보
- 수신 호스트 : 수신 윈도우 = 수신 버퍼 크기 - [마지막으로 수신한 바이트 - 마지막으로 읽어들인 바이트] - 송신 호스트 : 수신 윈도우 >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트 -> 수식을 유지하면서 송수신을 하면 자연스럽게 윈도우가 이동을 하면서 송수신을 하게 됨.
TCP 혼잡 제어 - 혼잡 (congestion) : 많은 트래픽으로 인해 패킷 처리 속도가 느려지거나 유실될 우려가 있는 상황 - 혼잡 -> 유실 -> 재전송 -> 혼잡 -> 유실 -> 재전송 -> ... - 혼잡이 생기지 않을 정도로만 조금씩 전송하는 방법
- 혼잡 윈도우: 혼잡 없이 전송할 수 있을 법한 양 -> 혼잡제어의 문제는 수신지에서의 문제 : 수신에서 송신에 - 송신 호스트 최소값(수신 윈도우, 혼잡 윈도우) >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
- 혼잡 제어의 기본 동작 형태 : 기본 동작 형태 : AIMD (Additive Increase Multicative Decrease) - 선형적으로 증가하고, 패키지 유실 발생시(혼잡도 증가) 바로 뚝 떨어졌다가, 선형증가 등등 - 선형적으로 증가하고 기술적으로 감소하는 형태
- 배경 지식: RTT(Round Trip Time) - 메세지를 전송한 뒤 그에 대한 답변을 받는 시간
- 느린 시작
- ACK 세그먼트가 수신될 때마다 혼잡 윈도우 1 증가 (RTT마다 혼잡 윈도우 2배 증가) - 특정 임계치(sshresh : 미리 정해둔 값)값과 같아지면 혼잡 회피 수행 - 임계치부터는 천천히 혼잡 회피( 매 RTT마다 혼잡 윈도우 1씩 증가 )를 함 : - 세 번의 중복 세그먼트가 발생했을 경우 빠른 회복 수행 : 빠른 재전송
