1주차
TCP/IP를 4계층으로 분석하라
링크 계층
OSI 7 계층에서 물리계층과 데이터링크 계층
링크 계층은 기본적으로 프로토콜을 정의하고, 물리적 영역을 표준화.
매체 접속 제어(MAC) 프로토콜이 링크상의 프레임 전송 규칙을 제어한다.(링크 접속 제어)
특히 RDT(신뢰적 전달)을 제공하는데, 전송 계층에도 RDT를 제공하지만 링크 계층에서도 제공하는 이유는,
네트워크 계층인 IP에서 best effort로 인해 데이터 손실이 일어날 수 있기 때문.
ARP (ip주소로 mac주소를 알아오는 거) -> 홉단위로 ARP
인터넷 계층(네트워크 계층) (IP)
IP는 경로를 알려주는 역할을 한다.
IP는 비연결 지향이고 신뢰할 수 없는 프로토콜.
그래서 링크 계층이나 전송 계층에서 RDT 를 확보해야 한다.
8비트 씩 4개로 32비트 주소체계를 가짐.
255.255.255.255 이런 식으로 십진수로 표기함.
CIDR 주소체계
x.y.z.0/a 이렇게 뒤에 prefix를 표기하는데, 앞에서 프리픽스까지는 네트워크 id를 의미함.
32-a는 호스트 id가 됨.
NAT
ip 주소가 부족해 지는 상황에서 로컬 네트워크는 사설 ip를 할당하는 것.
외부에서는 포트 번호를 활용하여 각 ip에 접근 가능하다.
IP, ARP, RARP, ICMP, OSPF
※ ICMP : 패킷정보 실패시 ERROR를 알리거나 해결 가능한 힌트를 제공하며, 주로 ping, traceroute를 할때 사용됩니다.
전송 계층(TCP/UDP)
데이터를 실제 송수신하는 역할.
네트워크 계층은 어떤 경로로 메시지를 전달하지를 결정
전송 계층은 도착한 메시지를 어떻게 처리 할 것인지 결정(엔드시스템에 존재.)
UDP는 비교적 간단하지만, 비연결 지향이고, 신뢰성없고, 순서가 뒤죽박죽으로 전달된다.
핸드쉐이킹도 하지 않고, 상대편이 어떤 상태인지 관심없다.
비트 손상이 일어날 수 있으나, 딜레이는 비교적 적은 편.(비디오, 오디오 서비스에서 활용.)
TCP는 신뢰성있고 순서대로 전송을 지원하지만, 비교적 복잡한 과정을 거침(그래서 IP와 함께 사용.)
한 연결에 한 리시버와 한 센더가 참여하고, 양방향 데이터 흐름을 가진다.
연결 지향이라 핸드쉐이킹을 가지고(3way) 센더와 리시버의 상태 정보를 기억한다.
센드 버퍼와 리시브 버퍼가 있어서 처리 속도가 전송 속도보다 느릴 경우 속도 조절(흐름제어).
TCP 혼잡제어 방식 : AIMD(최소단위로 시작해서 하나씩 늘려서 보냄. 혼잡 발생시 기존 전송량의 절반을 보냄)와 slow start(최소단위부터 시작해서 2^n씩 늘려서 보냄. 혼잡 발생시 AIMD방식으로 제어)
소켓은 두 프로그램(프로세스)이 통신하기 위해 양 쪽에 생성되는 링크 단자(인터페이스)
소켓은 어플리케이션 계층과 전송 계층 사이의 인터페이스.
UDP, TCP 여부에 따라 소켓에 필요한 정보가 달라진다.
소켓 API 흐름
클라이언트 : 소켓 열기(socket) -> 서버에 연결 요청(connect) -> 데이터 송수신(send, recv) -> 연결 종료(close)
서버 : 소켓 열기(socket) -> IP주소와 포트 번호를 소켓에 결합(bind) -> 연결 요청 대기(listen) -> 요청이 오면 수락한 후 소켓 연결(accept) -> 데이터 송수신(send, recv) -> 연결 종료(close)
어플리케이션 계층
서버와 클라이언트를 구현하는 계층(?)
이 과정에서 데이터 송수신의 규칙이 만들어짐.(네트워크서비스, 메일서비스, 웹서비스 등 표준적인 인터페이스)
OSI 7계층에서 세션, 프레젠테이션, 애플리케이션 계층에 해당
HTTP, FTP, Telnet, DNS, SMTP
서버는 항상 연결되어 있고 고정적인 IP 주소를 가짐. 클라이언트의 요청에 대한 응답을 하는 곳.
클라이언트는 간헐적으로 연결하고, 동적인 IP 주소를 가진다.(이동하는 경우), 통신의 시작점.
TCP의 3(4) way handshaking에 대해 설명하라
TCP 연결에서 데이터를 주고받기 이전에 서로가 준비 됐음을 확인하는 절차.
SYN : 연결요청 플래그
FIN : 연결중단 플래그
ACK : 요청확인 플래그
Seq : 시퀀스
통신을 시작할 때(3 way handshaking)
- 클라이언트가 자신의 seq를 x로 설정하고, SYN = 1, Seq=x를 헤더에 담아 서버에 보낸다.
(저는 x부터 시작할 거고요, 연결을 원합니다.) - LISTEN중이던 서버는 요청을 받으면, 자신의 seq를 y로 정하고,
SYN =1 , Seq = y, ACK = 1, ACKnum = x+1을 헤더에 담아 보낸다.
(잘 받았습니다. 저는 y부터 시작할 거고요, 저도 연결을 원합니다. ) - 클라이언트는 서버의 응답을 듣고,
ACK = 1, ACKnum = y+1를 헤더에 담아 서버의 응답을 확인했다고 전한다.
(확인했습니다.)
통신을 끝낼 때(4 way handshaking)
클라이언트가 소켓을 닫고, FIN = 1, seq = x를 담아 전달
(제 x번째 요청은 통신을 끝내는 거에요.)
이제 클라이언트가 더는 데이터를 보낼 순 없지만 받을 순 있다.
그리고 서버는 아직 연결을 종료하지 않았다.서버는 ACK =1, ACKnum = x+1을 담아 보낸다.(서버는 여전히 데이터를 보낼 수 있다.)
(일단 알겠습니다. 제가 보내야할 일을 끝내면 저도 통신 끝낼게요.)클라이언트는 서버의 ACK를 통해 자신의 종료 요청을 전달된 것을 알게되고,
이제 서버가 남은 일을 모두 끝낼 때까지 기다린다.서버는 데이터를 모두 보내고 나면, FIN = 1, seq = y를 보낸다.
(저도 이제 남은 일 다 끝났습니다. 이제 연결을 끝내죠.)
이제 서버도 데이터를 보낼 수 없게 된다.클라이언트는 서버의 종료 요청을 듣고, ACK =1 , ACKnum=y+1을 보낸다.
(알겠습니다. 연결을 종료합니다.)이때 중요한건, 자신의 ACK요청이 잘 전달됐는지를 확인하기 위해서 잠시동안 대기한다.
ACK 요청이 전달되지 않으면 재전송해야 될 수 있기 때문이다.
대기 후 연결을 종료한다.
난수인 seq를 보내는 이유
서버 측에서 패킷의 seq를 보고 패킷을 구분.
난수로 보내야 패킷을 혼동없이 구분할 수 있음.