요약

• 전송 계층 : IP의 한계를 보완
• IP 한계 : '최선형 전달', 비연결형 프로토콜
• 포트 번호 : 특정 애플리케이션을 식별하는 정보

전송 계층

• 아래의 IP의 한계를 보완하는 계층이다.

IP	한계
신뢰할 수 없는 통신	IP 프로토콜이 패킷이 수신지까지 제대로 전송되었다는 보장을 하지 않음/ ' 최선형 전달'
비연결형 통신	성능때문에 비연결로 통신함(속도는 빠름)

당연하게, 전송 계층은 보완을 한다했으니
1. 신뢰성 있는 통신
2. 연결형 통신이 가능하다. (= 대표적으로 TCP)

그럼, 비연결형, 신뢰할 수 없는 통신은 없는가? UDP가 있다.

포트(Port)

• 패킷이 실행 중인 특정 애플리케이션까지 전달되려면 패킷에 특정 애플리케이션을 식별할 수 있는 정보
• 포트 번호를 통해 식별한다.
• 포트 번호에는 잘 알려진 포트,등록된 포트, 동적포트, 사설포트,임시 포트가 있다.
  잘 알려진 포트와 등록된 포트는 이미 사용하고 있는 포트번호이다.
  서버로서 동작하는 프로그램의 포트 번호는 사전에 암묵적으로 정해진 경우가 많다. (유명한 사이트 HTTP-80)
  반대로 클라이언트는 임의 번호가 할당되는 경우가 많다.
• IP 주소와 포트 번호가 주어지면 특정 호스트에서 실행중인 특정 애플리케이션 프로세스를 식별할 수 있다.

IP 주소:포트 번호

위 형식으로 주로 포트 번호를 표기한다.

사설 IP주소와 공인 IP주소가 1대1 대응을 하지 않는 경우가 많다.

• 만약 1대1로 대응하려면 사설 IP 주소만큼 공인 IP 주소가 필요하기 때문에 그렇게 하지 않는다.
  이때 포트를 활용한다. 포트 기반의 NAT NAPT를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하는 NAT의 일종
  즉, 포트 번호로 식별해서 어디 호스트로 가세요~라고 알려준다. 이렇게 하면 공인 IP 주소 부족 문제를 해결할 수 있다.

TCP & UDP

TCP

TCP 통신 단계
1. 연결 수립
2. 데이터 송수신
3. 연결 종료

• 연결 수립과 연결 종료를 알기 전에
  MSS(Maximum Segment Size) 를 알아야한다. TCP로 전송할 수 있는 최대 페이로드 크기를 의미(TCP 헤더는 제외)
  MTU는 헤더 크기 포함
• 추가적으로 제어 비트
  ACK : 세그먼트의 승인을 나타내기 위한 비트
  SYN : 연결을 수립하기 위한 비트
  FIN : 연결을 종료하기 위한 비트

*여기서 세그먼트는 TCP 헤더가 각각 포함된 패킷의 잘게 조개진 조각이다.

연결 수립

• 3-way handshake

  여기서 그 유명한 3웨이 핸즈 쉐이크가 나온다.
  
  출처

1. Client -> Server : SYN '연결 시작합니더~~'
2. Server -> Client : SYN + ACK '넵! 확인했습니다. 시작하시면 됩니다.'
3. Client -> Server : Ack '넵 확인했습니다.'

데이터 송수신

제전송을 통핸 오류 제어, 흐름 제어, 혼합 제어를 수행

1. 오류 제어
   TCP 세그먼트에 오류 검출을 위한 체크섬 필드가 있지만 이는 세그먼트의 훼손 여부만 나타내고, 이 값이 잘못되었다면 호스트는 해당 패킷을 읽지 않고 폐기한다. 그래서 송신 호스트가 세그먼트 전송 과정에 문제가 있다는 것을 인지할 수 없다. (수신자가 폐기하므로)
   즉, 송신 호스트가 문제가 있음을 알아야한다.

• 중복된 ACK 세그먼트를 수신했을때
  -Client -> Server : N번 받아라~
  -Server -> Client : N+1줘! -> 위 데이터를 보내고 Ack받는 데 걸리는 시간을 RTT라고함(Round Trip Time)
  -Client -> Server : N+1보냄(누락됨)
  -Server -> Client : N+1달라고~

• 타임아웃이 발생했을때
  -TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머라는 값을 유지함
  즉,
  Client -> Server : 타이머 시!작!
  ... 타임 아웃
  Client : 너 데이터 제대로 못받았구나? 다시 줄게!
  Client -> Server : 다시받아 (타이머 시작!)

오류에 대해서는 알아봤고, 그럼 이제 TCP의 재전송 기법을 보자!

• ARQ(자동 재전송 요구)

ARQ	설명
Stop-and-wait ARQ	가장 단순한 방식, 제대로 전달했음을 확인하기 전까지 새로운 메시지를 보내지 않음, 높은 신뢰성을 보장 BUT 네트워크 이용 효울이 낮아짐(계속 대기를 해야하니깐 성능 저하 발생)
Go-Back-N ARQ	여러개를 연속해서 메시지를 보냄(이런 기술을 파이프 라이닝) 즉, N보냄 -> N+1보냄 -> N+2보냄 이때 응답이 오지 않는 세그먼트부터 다시보냄 '누적 확인 응답'이라고도 함
Selective Repeat ARQ	선택적 재전송, '개별 확인 응답' 위와 다르게 응답이 없었던 세그먼트만 다시 보냄

현대 TCP는 '파이프 라이닝'이 사용되는 Go-Back-N ARQ와 Selective Repeat ARQ를 기반으로 동작

2. 흐름 제어

• 수신 버퍼 : 수신된 세그먼트가 애플리케이션 프로세스에 의해 읽히기전 임시로 저장되는 공간
  저장 공간보다 더 많게 되면 버퍼 오버플로가 일어난다.
  '파이프라이닝' 기반에서만 일어난다. (그외에는 응답이 와야 데이터를 보내니깐)
• TCP는 흐름 제어로 슬라이딩 윈도우를 사용한다.
  TCP 세그먼트 내에 윈도우라는 필드가 존재했는데, 여기에 수신 윈도우의 크기가 명시되고, 이는 한 번에 수신하고자 하는 데이터의 양을 나타냄 그래서 ACK 응답이 오면 슬라이팅 하듯이 옆으로 다음 세그먼트로 N~N+(윈도우 크기) -> N+1 ~ (N+1)+(윈도우 크기) 이런식으로 옆으로 이동한다.

3. 혼합 제어

• 혼잡 윈도우 : 혼잡 없이 전송할 수 있을 법한 데이터양 (절대적인게 아니라 이정도면~ 괜찮지 않을까~?)
  이를 알아내기 위해 혼잡 제어 알고리즘을 사용한다.

알고리즘 종류	설명
AIMD	혼잡이 감지 되지 않으면 혼잡 윈도우를 RTT마다 1씩 선형적으로 증가시키고, 혼잡이 감지되면 절반으로 떨어뜨리는 동작을 반복
느린 시작	혼잡 윈도우를 1부터 시작해 문제없이 수신된 ACK 세그먼트당 송신 세그먼트를 1개씩 추가하는 방식 결과적으로 RTT마다 2배씩 지수적으로 증가 / 계속 증가할 수는 없다. 느린 시작 임계치를 사용
혼잡 회피 알고리즘	RTT마다 혼잡 윈도우를 1MSS씩 증가시키는 알고리즘
빠른 회복 알고리즘	세 번의 중복 ACK 세그먼드를 수신했을 때 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘 , 빠르게 전송률을 회복하기 위한 알고리즘

연결 종료

출처
1. Client -> Server : FIN '연결 끊습니다'
2. Server -> Client : Ack '확인했습니다'
3. Server -> Client : FIN '이제 연결 끊습니다.' -> 일정 시간 이후 보내는 이유 _ ACK가 제대로 전송되지 않았을수도 있어서
4. Client -> Server : Ack '네 확인했습니다'

• 이처럼 TCP는 상태를 유지하고 활용한다는 점에서 스테이트풀(stateful) 프로토콜이라고 한다.

연결이 수립되지 않은 상태에서는 어떻게 하고 있는가?

주로 CLOSED(연결 없는 상태), LISTEN(대기 상태)을 하고 있다.

UDP

• 스티이트리스(stateless) 프로토콜이라고 한다.
• 연결을 하지 않고 그냥 패킷을 보낸다. 이래서 TCP보다 빠르기 때문에 영상, 인터넷 전화와 같은 경우에 많이 쓴다.

---

기본 숙제

IP와 연관된 통신 특성으로 알맞은 단어를 <보기>에서 골라 보세요.(p.206)
비신뢰성, 비연결성

다음은 TCP 쓰리 웨이 핸드셰이크 과정을 나타내는 그림입니다. 괄호 안에 들어갈 말을 <보기>에서 골라 보세요.(p.225)
(Ack) 세그먼트

추가 숙제

작업 관리자에서 프로세스별 PID 확인해 보기

크롬만 가져왔다. 각 크롬의 PID이다.