[Full-Stack Network] 3. OSI Architecture (L4)

• 실시간으로 화상 전화 : UDP 비율이 높음 -> 빨리 전달하는 것이 중요하기 때문
• 영화 : TCP 많이 쓰임 -> 화질이 중요 / 미리 시간을 끌어서 그동안 에러 복구해서 화질 좋게함
• 요즘은 영상을 UDP + http3

과거에는 안정성 추구 -> TCP 추구
최근에는 UDP가 많이 쓰인다

2계층 기능 : 에러검출, 플로우 컨트롤
가장많이 쓰는 유무선 통신의 방식은 에러 검출의 한계가 있고, 보내기도 전에 자멸할 가능성도 있어서 사실 구현이 됐을때는 flow control의 말도 안꺼냄

🍏 Transport Layer

• Error 검출 및 복구
• Flow Control
• L3에서 엉망된 순서 관리
• Congestinon Control

ps) 3주차 소켓 통신 : TCP UDP 위에서 짜는 것

• Transport Layer Header : 어느 프로그램이 보냈는지에 대한 정보 = Port num
  이걸 보고 맞는 Process 를 찾아서 전달.

✅ Process to Process Delivery

• Network : Host to Host (컴퓨터 A - 컴퓨터 B)
  목적지 컴퓨터 찾기
• Transport : Process to Process
  컴퓨터에 도달한 message를 올바른 Process에 전달

✅ Client/Server Paradigm

기능적으로 구분

• Client : local host에서 요청
• Server : 요청을 받아 서비스를 제공

✅ L4 Addressing

OSI L1,L2는 공장에서 정해지는 것

• L4의 주소 = Port num (16bit)
• Well-known port number : for 서버 (0~1023)
  OS 자체 or 기본적인 서비스는 Port 번호가 이미 정해져 있다 ex) 이메일
  따라서 이 번호를 무단으로 사용하면 충돌! 사용하면 안됨!

서버의 port num은 고정 (ex 13)
client는 안중요함 계속 바뀐다.

✅ Socket Addresses

• IP Add + Port Add
• 전세계에서 유일하게 program을 식별할 수 있는 번호

✅ Multiplexing and Demultiplexing

별로 중요 X
하나의 OS 위에 다양한 program이 동작한다

✅ Connectionless vs Connection-Oriented Service

TCP/UDP 왜 나눠지는가
Connection : 가상적인 연결 / 통신 전에 손잡고 약속!

• Connectionless (UDP)
  Error 검출 및 복구 X
  Flow Control X

• Connection-Oriented (TCP)
  Error 검출 및 복구 0
  Flow Control 0
  -> 가상의 줄을 만들어서 data를 주고받는다

✅ Reliable vs Unreliable

• Reliable (TCP)
  process는 TCP를 믿는다. 알아서 TCP가 해주겠지~ 복잡한건 몰랑
  TCP가 하는게 많아서 복잡하고 slow해짐
  ex) 영상 - 화질은 좋아지지만 버퍼링 발생
• Unreliable (UDP)
  연결 설정 해지 따위는 없음
  flow, error control x

그럼 UDP 왜써?
글고 Data link에서 에러컨트롤 하는거 아니야? -> 아래에서 계속

✅ Error Control

• 한 프로그램 내에서 packet이 유실될 가능성도 있고, 몰리는 현상 등

• Transport에서 끝과끝에서 error 검출 및 복구

• 시험 문제 : reordering, port에 몰리는거 기타 등등을 쓰면 점수 부여~

네트워크는 믿을게 못돼

✅ Transport Layer Protocols

🍏 UDP

= protocol
= User Datagram Protocol

• connectionless
• unreliable

신뢰성 보장이 필요없을 경우 UDP 사용

• UDP를 쓰는 상위계층 애들
  DMS - 53
  File 송수신 - 69

✅ UDP - Frame Format

UDP가 실어나르는 Header (8byte)

• 보내고 받는 사람 Port num
• 전체 길이
• Header가 깨진지 확인하는 checksum

대충 이런것들이 있다~만

✅ UDP - Operation

• Connection less
  허락없이 그냥 보낸다
• datagram : UDP가 전달하는 정보
  앞뒤 상관관계가 없음
• UDP가 하는 것 : user가 준 정보에 port num을 붙여서 전달
• flow, error control XXXX

p.22
Client, Sever입장에서 어떻게 동작하는지 살펴보장

✅ UDP - Queuing

• Queue : 버퍼 / FIFO

Outgoing queue에 차례로 넣어두고 주기적으로 읽어서 처리. 상대방의 속도에 말리지 않도록. 너는 쓸만큼 써~ 나는 내 페이스대로 읽을게

Layer to Layer로 속도 조절. buffer에 빈 공간이 없으면 기다린다.

✅ Queuing at Client site

• TCP UDP는 OS에 있다 = OS 주인의 허가가 없으면 수정 불가 -> 안쓰기 시작하게 됨

client의 port num은 중요 X
program이 살아나면 OS가 준 random num이 뜨고 UDP에게 이 번호를 뚫어달라고 함 . 그럼 queue들 확보.

• UDP가 받은 정보 메세지를 server가 가져갈 수 있도록 incoming queue에 전달
• 상위계층의 메세지를 outgoing queue에 써주면 UDP가 내보낸다.

✅ Queuing at server site

• server는 누군가 요청하기 전에 살아있어야 한다.
• server가 시작되면 UDP에게 outgoing, incoming queue를 요청 = port를 뚫는다
• UDP가 전달한 message를 받고 본인이 전달해야할 메세지를 outgoing queue에 담는다.

✅ Applications

UDP는 port num으로 process 식별 외에 기능이 없음

• AB가 매우 멀리 떨어져있는데 둘 간에 error가 발생할 것 같으면 안씀 ex) FTP
• UDP 위에서 TFTP를 이용하면 에러검출 좀 가능
  example)
• Broad Casting : 상대방이 누구든 난사
• Router to Router Communication

✅ Q. Message Copy?

7layer에서 layer을 통과할때마다 메세지 copy가 되면 layer 올라갈수록 느려질것임. 그래ㅑ서 그렇게 안함. 7계층에서 만든 data를 6계층에서 전달할 때 7이 쓴 memory의 시작과 끝 포인터를 6계층에 전달. 위에서 받은 메세지
밑으로 내려가면 data는 주소값만 전달이 될 뿐 copy X (zero copy) 동일한 컴퓨터에서 상위 sw가 하위 sw로 전달할 때 복사하지 않고 포인터값만 전달한다. 그래서 unix를 만들기 위해 c언어를 쓸 때 포인터가 중요했음.

🍏 TCP

하는 일이 많아요~

• connection-oriented
  쏘기 전에 악수하기
• virtual connection
• flow & error control

• 1990년대 : data를 보낼 때 신뢰성있게 보내는 것이 중요해서 TCP 사용
• 1990 중반 : TCP 보다 HTTP 위에서 짭니다. 매우 easy.
• HTTP : 신뢰성을 원했지만 새로 짜기 싫었기 때문에 처음에 TCP 쓰겠다고 선언. 1990 부터 2010년대 HTTP가 TCP를 사용해서 TCP 사용. http도 3부터는 UDP사용.
• HTTP가 결국은 대세가 돼서 프로그램도 http 위에서 사용. 실제로 동영상 주고받는 것도 다 http. 인터넷 트래픽의 대부분이 HTTP.
• http의 port num = 80
  C/C++는 http library 제공 X

✅ Stream Delivery Service

Sending process & Receiving process

• stream oriented protocol
• virtual connection
  pipe를 열어두고 트래픽을 흘려보낸다
• stream of bytes

✅ Sending and Receiving Buffers

buffer를 pipe로 이어준다.
buffer의 개수, buffer를 언제 만들지 기타 등등은 처음 연결할 때 결정

[보내는 쪽]
sending process가 buffer에 데이터를 쓰면 차곡차곡 쌓인다.
상대방이 잘받았다/못받았다 대답하기 전까지 buffer에 담아둔다.
못받았다면 다시 보내고 / 잘받으면 buffer에서 지우기

• Not sent : 보내지 않은 것
• Sent : 이미 보낸 것

[받는 쪽]

• Not read : 받아서 미리 저장은 해놨지만 process가 아직 읽지 않은 것. 읽으면 그 후에 지운다

✅ Segments

• UDP : datagram
• TCP : segments

Segment = 5계층 이상에서 준 data + 본인이 집어넣은 정보(header) + 기타 정보들(에러검출)

receiving segment의 순서가 바껴있거나 유실되었을 경우 재전송
TCP에서의 복구 = 재전송 (resent)

process가 만든 핑크색 data + TCP의 Header
TCP는 byte 단위로 전송

✅ Full-Duplex Service

• 보내면서 받는게 동시에 가능
• Piggybacking
  받는 입장에서 에러관련, 속도관련 의 정보들을 보내는 쪽에 알려줘야 한다.
  상대방에게 보낼때 이 정보를 붙여서 보낸다 (like 돼지 꼬리)
  기본적으로 A가 B에게 본인 data를 보내면서 B가 A에게 보낸 ACK관련 정보를 붙여서 보낼 수 있다.

✅ Byte numbers

TCP는 내가 상대방에게 segment형태로 보내고 있긴하지만 byte의 단위로 count한다.

• length field : size
• number range가 한정되어있어서 circular하게 할당
• flow & error control

✅ Sequence number

• segment가 실어나르는 data의 첫번째 byte의 번호
• 포인터 느낌

✅ Acknowledgment number

• 받는 쪽에서 사용
• 상대이 보낸 sequence num에 대한 대답
• 니가 보낸 거 잘 받았엉. 다음꺼 내놔

✅ TCP segment format

• window size : flow control
• control field: 빨간 bit가 1인가 0인가에 따라 특수 목적을 수행

server에서 C/C++이 전통
Go도 떠오르긴하지만 아래 계층에서는 C/C++이 필요함.

✅ Control field

• SYN = 상대방이 연결요청을 한 것.
• FIN = 연결 해제
• ACK = 응답. 좋아!
• RST = 최초의 값으로 모든 값을 초기화
• URG & PSH 는 아래에서

✅ TCP - Connection-Oriented

• source와 destination 사이에 virtual path가 필요하다.
• TCP는 복잡하고 많은 field를 통해 에러 검출 및 복구
• IP는 연결설정 & 해체 X
• TCP 밑에 신뢰성 보장안된 애가 와도 상관 X 그냥 거기에 맞게 동작하면 됨

✅ TCP - Connection-Establishment

• full-duplex
• 대신 연결 설정 및 해제는 미리 해야겟죵

• 연결 설정
  
  실제로 통신을 맨처음 시작하는 게 누구의 요청으로 시작? (client or server)
  단말이 요구하지 않으면 server는 응답하지 않는다.

• Simultaneous Open
• SYN Flooding Attack
  굉장히 많은 buffer와 CPU Procesesing을 먹기 때문에 TCP 연결이 많아질 수록 불안해진다. 계쏙 쏘아버리면 server가 터질 수 있음.

✅ TCP - Data transfer

• Pushing Data
  보내는 data 마다 TCP header를 붙여야함. 헤더 완전 큼. 그래서 그걸 바로바로 보내면 TCP들은 효율을 높이기 위해서 일정시간 동안 버퍼가 어느정도 쌓이면 보냄.
  급하기 보낼 data가 있으면 Push를 요청. 기다리지 않고 바로 내보냄
• Urgent Data
  보내면서 urgent를 세팅해서 보내면 상대방도 바로 applciation 쪽으로 밀어낸다.
  -> 거의 안씀

✅ TCP - Connection termination

너는 보낼 거 없으니 해제 ㅇㅋ 근데 나는 좀 보낼게

✅ TCP - Flow Control

✅ TCP - Normal operation

• 관점 : 정해진 시간안에 많이 보내기
• 안정성을 추구했던 flow control과 다른 관점
• 타이머 사용(보통 500ms)

✅ TCP - Lost segment (error)

• error의 가장 기초 : 가는 메세지가 없어지는 것
  = buffer의 overflow가 생기거나 error로 중간장치가 이해를 못해서 버리기도 함
• 시간안에 응답이 안오면 재전송
• TCP는 못받은 애를 비워두고 제대로 된 애를 넣어 놓음

-> 완전 timer based

✅ TCP - Fast retransmission

timer based로 ack를 보내는 것이 아니라 바로 바로 보낸다.
301 보내줘! 를 여러개 받으면 timer상관없이 바로 보냄.

✅ TCP - Lost ACK

✅ TCP - cwnd Increase

• cwnd를 조절해서 쏠 수 있는 양을 조절
• network는 특정순간에 너무 많은 트래픽이 모일 수 있다. 그래서 sender는 중간에 있는 장치들이 넘칠까봐 조절해서 보낸다. 조금씩 양을 늘리거나 2배로 늘리거나.

✅ TCP의 가장 큰 문제점

아무리 초고속 인터넷을 써도 결국 TCP 성능이 출렁출렁
우리가 server에서 file을 하나 다운받을 때 TCP 줄이 하나면 저 표처럼 다운..

Q. 그럼 TCP 성능을 어떻게 올릴 수 있을까?
client-server 사이 TCP연결을 여러개 만듦
예를 들어 4개 만들었다면 서버에서 파일을 네개의 서브파일로 쪼개서 전송.
동시다발적으로 보내면 속도가 3.X까지 올라감. http 1.1에서 정통적으로 쓰는 전송 기법임.
요약 = TCP 세션을 병렬적으로 열어서 동시다발로 받아서 속도 up