201104일자 답변 : https://gall.dcinside.com/board/view/?id=programming&no=1515784&_rk=96k&s_type=search_name&s_keyword=%EC%B7%A8%EC%A4%80%EC%83%9D&page=1


재밌는 아티클 첨부합니다 :

“왜 인터넷은 근본부터 글러먹었는가”

 https://unifiedh.com/ko/why-the-internet-is-fundamentally-flawed-ko/


각설하고 오늘자 답변:

출처 : https://github.com/WeareSoft/tech-interview#2-network


1. OSI 7 계층

ISO에서 네트워크 통신 단계를 7단계로 나눠놓았습니다.


단계별로 나눠서 얻는 이점

  1. 기능별로 나눴기 때문에, 각 층에서는 그 기능만 집중가능.
  2. 그말인 즉슨, 문제가 생길때 원인 파악하기도 쉬움. 매 계층마다 값 검증하는것도 비교적 용이함.
  3. 진행 방향도 일정해짐. 각 계층의 상위단계는 하위단계에서 올려주는 값을 활용해서 값을 새로 만들고 그 상위 단계로 이동 가능. 
    1. 예) 물리단에서 MAC주소로 프레임만들고 전송 -> 네트워크단에서 라우팅해서 IP 찾아서 패킷만들고 다음 계층으로 전송.


어떤일이 일어날까요?


보내는쪽에서는

1번이 2번한테 요청하려고합니다.

1번은 2번의 ip주소는 아는 상태.

어플리케이션에서 send(“1.1.1.2”) 한 상태.

  1. IP계층에서.. 라우팅 테이블 참고해서 어디로 나가야할지 체크함.
  2. 맥 주소 참고해야함.  외부 네트워크 맥주소가 없을테니까 ARP 테이블 참고함.
    1. ARP테이블에 없다면 ARP Request까지 보냄.
  3. 맥주소 알아왔으면 보내기!

받는쪽에서는

  1. 어느 클라이언트로 보내는지 패킷 까보면서 최종적으로 클라이언트에 보냄.

2. TCP와 UDP

TCP는 제어연결 다함.

흐름제어, 혼잡제어, 순서보정 등 신뢰성 있는 연결.

계속 서로 정보 체크하면서 맞는지 확인하면서 보냄.

 

UDP 비연결형 서비스.

체크섬을 통한 최소한의 오류만 검증하고 확인 이런거 없음.

실시간 스트리밍에 이용됨.


3. TCP와 UDP의 헤더


tcp는..

Source pot, destination port

Seq #, ack #,  window size, Flag bit … 그외 여러 필수적인거..


udp는..

Source port, destination port + checksum + length…


4. TCP의 3-way-handshake와 4-way-handshake 


3 way hand shake

  1. A -> B : SYN 
    1. A가 B에게 연결 요청 
    2. Sequence number를 임의의 랜덤숫자로 지정 그 값을 SEQ # 에 넣는다. SYN flag 1로 수정.
  1. B -> A : SYN + ACK
    1. B가 A에게 연결 요청 및 응답.
    2. ACK # = 전달받은 A의 SEQ #값 + 1 (패킷 순서 확인차). 그리고 B도 자기의 SEQ # 값 넣어서 전달. SYN flag = 1, ACK flag= 1
  1. A -> B : ACK
    1. A가 확인 메세지 보냄.
    2. ACK # = 전달받은 B의 SEQ #값 + 1 

4 way hand shake


  1. A -> B : FIN 
    1. A 앱이 끝내기 요청.
    2. A는 FIN WAIT 상태 (끝내기를 기다린다) : 아직 닫히진 않음. 
  1. B -> A : ACK
    1. A에게 FIN을 받았음을 응답함.
    2. 하지만 서버쪽에서는 아직 보낼게 있을 수 있으므로, 서버쪽 전송이 끝날때까지 기다린다.
    3. B는 CLOSE WAIT 상태 (B쪽이 완전히 끝나기를 기다리는 상태) 
  1. B -> A : FIN
    1. 드디어 B가 끝나고 FIN을 보냄.
    2. LAST_ACK 상태 (A로부터 마지막 ACK를 기다린다)
  1. A -> B :  ACK
    1. A는 B의 fin 호출을 받고 닫을 준비를 한다.
    2. 단, 네트워크는 항상 혼잡하고, 제시간에 제순서대로 들어오지 않는다고 가정하기때문에 fin패킷이 다른 데이터 패킷보다 먼저 들어왔을 수도 있다. 
    3. 만약 연결을 닫아버리면 그 데이터패킷은 소실되기떄문에, 일정 시간동안은 기다려준다. 그다음에 닫는다. 그 상태를 time-wait이라고 한다.
    4. 그 시간이 지나면 최종적으로 닫는다.

Q. TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유? 

클라이언트가 전송다했다고 서버도 전송 끝이 될수가 없음.

각각 자기가 끝내는것을 결정해야함.

그래서 4단계. (클라이언트 끝, 끝 확인, 서버 끝, 끝 확인)


Q. 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?

위에설명


Q. 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유?

랜덤하게 안보내고 다 0으로 시작했다고 해보셈.

SEQ 0 이기 때문에 누가 그냥 ACK = 0+1 해서 보내면 패킷 변조가 되버리는거. (ACK는 항상 +1씩 증가)

그래서 랜덤하게 변경해서 시작함.