Transport layer

TCP / UDP

TCP의 데이터 전송
데이터를 보내기전에
ex)넌 전송속도가 얼마야?
     난 서버니까 빠르지
처음 데이터 몇개를 보내고 정상적으로 받았다는 응답을 받는다. 
데이터를 못 받은경우 못 받았다라고 재 전송

다른말로 연결 통로 확립 후에 데이터 전송

세션이란
사용자와 서버간의 논리적으로 만들어진 연결
(눈에 보이지 않는 통로)
ex) 전화기로 누구에게 전화하면
      누군가에게 벨이 울린다
     ->그 사람이 통화를 받는 순간 세션 수립

[ 3 Way HandShake ] - 세션 수립

5번까지 잘 받았다.
6번 Acknowledge 보냄. [잘 받았다.]

흐름제어 ( Flow Control)
Sliding Windows 방식을 사용. (TCP에서 흐름제어)
윈도우 사이즈 결정
윈도우 사이즈 = 물통장수가 물을 채울때 그 집안의 물통을 채울 때, 
한번에 얼마만큼 양을 넣을지 조정

 - 즉 -> 응답을 받지않고 보낼 수 있는 데이터의 사이즈

UDP의 데이터 전송
Best effort 주변 상황에 따라서 속도가 달라지는 경우.
TFTP (Trivial File Transfer Protocol)
신뢰성 X (연결 통로 확립 하지않는다. 세션 수립 X)

TCP는 100M 다운받으면 항상 100M /  TFTP는 100M받으면 항상 100M가 아닐 수도 있다.

UDP는 TCP에 비해 재전송이 없어서 속도가 빠르다. (세션수립도 x)

cisco 라우터 , 스위치 등에서 부팅할 때 IOS 이미지가 없을때 TFTP에서 찾아서 다운받아 실행
네트워크 환경이 좋아 졌기때문에 가능. 
(TFTP서버를 라우터에 같이 혹은 한 HOP 정도 떨어져서 설치)

TCP가 IP에 담겨서 보낼 수 있는 이유.
우편같은 경우도 전달해 나가는 데이터가 어떤 데이터냐에 따라서 직접전달한다.
IP는 PC에서 PC 까지 연결만 담당.
UDP와 TCP는 통신하는 주체가 프로그램(Application)이기 때문에 역할이 다르다.

세션수립 :
신뢰성 : 
순서 재구성 : 서로 다른 전송속도를 가질 수 있는 여러 경로를 제공 할 수 있기 때문에 잘못된 순서로 도착할 수 있음. 
이 경우 시퀀스 번호가 매겨진 순서를 보고 다시 재구성하여 순서를 확인 할 수 있음.

흐름 제어 : End to End 방식을 사용 송신측과 수신측의 데이터처리 속도 차이를 해결하기 위함
수신측이 송신측보다 속도가 빠른 것은 아무문제가 되지 않지만, 반대의 경우 문제가 발생함. 
서비스 하는 속도보다 송신측에서 보내는 데이터 속도가 더 빠르다면, 
수신측에서 제한된 저장용량(일반적으로 큐)을 초과하여 이후에 도착하는 데이터의 손실을 가져옴 이럴 경우 강제로 송신측의 데이터 전송을 줄임
방식 :  Stop and wait 방식 : 매번 전송한 패킷에 대해 확인응답을 받아야 그 다음 패킷을 전송하는 방법
슬라이딩 윈도우 기법 : 수신 측에서 설정한 윈도우 크기 만큼 송신 측에서 확인 응답 없이 세그먼트를 전송할 수 있게해 데이터 흐름을 동적으로 조절하는 기법

nslookup 도메인 - ip서버 확인 명령어
네이버라던지 웹 서비스 wireShark로 패킷 분석하면 클라이언트에서 연 port, 서버에서 연 port랑 각 프로토콜의 port번호가 소켓(한쌍)으로 페어 되어있다.
       20번 FTP :파일전송 데이터 용
TCP 21번 FTP : 속도 조절 및 컨트롤 용

netstat  : 포트의 프로토콜로 나타남
netstat -n 상세하게 포트번호

https://4network.tistory.com/entry/windowsize

3way handshake 악수
송신자가 Syn 동기화 패킷
수신자가 Syn  + Ack  flags 1로 set해서 보낸다. 동기화신호 + 신호 잘 받았다는 확인 패킷
송신자도 Ack 패킷 보낸다. 잘 받았다는 뜻.

4way handshake
송신자 혹은 수신자가  Fin 보낸다. 
응답받은 지체가 ACK 보낸다 그리고 Fin보낸다.
최초 발신자가 ACK보낸다.

stop and wait 방식 / sliding window 방식 (windows Size)
stop and wait는 받고 기다렸다가 하는데 느리다.

Sync 씽크라는것은 초기에 연결 설정을 하는 것이다. 씽크가 안맞다.. 씽크를 받아야 응답을 한다. 

그래서 슬라이딩 윈도우 방식은
송신측에서 정한 윈도우 사이즈만큼 보낸다. 한번에 받을 수 있는 양
버퍼크기 이하의 사이즈는 보낸뒤 확인 없이 바로 보낸다.

FIN 신호를 보냈는데 ACK만 보내고 FIN을 안 보냈을 때.
옛날에 전화 걸었을 때 '내가 너희 집 도둑질 할 거다 키키' 당한사람은 전화를 끊고 112에 신고 할려고 하는데 악.. 전화가 안돼 상대방이 전화를 안 끊었어.
실제로 강도질 당함 -> 이슈가 되어서 한쪽에서 세션을 끊으면 일정 시간 후에 자동으로 세션이 닫힌다. (닫히도록 설정 했다.) 

선한 용도로 만들었는데, 해커들이 Syn 신호 보내서 사용중인 포트번호를 알아내서, 어떤 프로토콜 서비스가 사용되는지 유추하고.
Mnet 시스템? 포트 쭉 스캔해서 정보를 모은다. 대상 시스템의 열려있는 포트만 보고 pc인지 server인지도 유추 할 수 있다. 해킹의 대상이 될 수 있다..