[허언증/네트워크] chapter02-② (성공과 실패를 결정하는 1%의 네트워크 원리)

안녕하세요 허언증 입니다.

 

책에 있는 내용을 이해하고 서술 하듯 글을 적어 내려 갑니다. 저도 공부하는 차원에서 정리하는 글 이고 네트워크 과정에서 생략되는 부분도 발생할 수 있기 때문에 부족한 점도 있다는거 인지 하시고 편안하게 읽어주세요!! 역사처럼 물 흐르는식으로 스타일로 글을 작성합니다.

 

 

 

---

 

chapter02

 

1.소켓을 생성한다.

2.서버에 접속한다.

3.데이터를 송/수신한다.

4.서버에서 연결을 끊어 소켓을 말소한다.

5.IP와 이더넷의 패킷 송/수신 동작

6.UDP 프로토콜을 이용한 송/수신 동작

 

 

 

---

3. 데이터를 송/수신한다.

 

 

Connect를 통해 애플리케이션에 제어가 오면 송/수신 동작으로 들어간다.(②단계) 이 동작은 애플리케이션에게 write()를 호출하여 송신 데이터를 프로토콜 스택에 건네준다. 위 그림에서 (③단계)이다.

 

이 때 중요한 점은 애플리케이션에서 -> 프로토콜스택에 Write() 명령을 통해 전송하는데, 2가지 상태 특징을 기억하자!!

 

첫 번째 프로토콜 스택은 단지 버퍼 메모리에 저장하기 위해 데이터의 크기는 알지만 세부내용은 알지 못 한다.

두 번째 상황에 따라 분할해서 전송 / 한 번에 전송 크게 2가지 방식으로 나뉜다.

 

2개의 항목 중 마지막 두 번째에 대해 이야기를 더 하도록하자. 

만약 데이터를 받는 즉시 송신을 한다면? 패킷을 계속 보내기 때문에 네트워크 이용 효율이 떨어질수도 있다.(한 통신만 계속 하는게 아니기 때문) 그렇다면 일정량의 데이터를 저장 후 전송하는게 효율적이라 생각을 하게 된다.

그럼 어느정도 데이터를 저장했다가 전송을 한 것인가?

OS의 종류에 따라 방식이 다르지만 판단 요소는 1)데이터 크기 2)타이밍 으로 정한다. 

 

 

 

 

 

우선 "데이터의 크기"는 프로토콜 스택은 MTU라는 매개변수를 바탕으로 판단한다. MTU는 한 패킷으로 운반할 수 있는 데이터의 최대길이 이더넷에서 보통 1,500Byte이다. MTU는 데이터 +헤더를 다 포함한 범위이고 순수 데이터만 포함하는 명칭은 MSS이다 만약 MSS의 데이터가 최대 길이보다 긴 데이터를 송신을 하면 분할해서 전송을 한다. MTU와 MSS 길이를 어떻게 정하고 설계를 했는가에 따라 영향을 크게 받게 된다. 타이밍은 애플리케이션이 자체가 속도가 느리면 그걸 인지를 하고 적절한 시간에 송신한다! [아래 표 정리]

 

 

 

 

 

이제 입력한 패킷이 서버로 향해  송신이 된다. 지금까진 송신에 대한 설명을 하지 않고 그냥 송신이라고만 했지만 이번엔 좀 더 자세히 설명하려고 한다.

 

 

chapter02-① (성공과 실패를 결정하는 1%의 네트워크 원리) 에서의 마지막 부분에 ACK, SYN에 대해 이야기를 했었는데 이 과정을 알아보도록하자.

 

데이터를 잘 받았는지 확인하기 위해 시퀀스 번호를 통해 확인을 하는데 위 그림을 보면 SYN 값이 1로 시작을 했다고 가정을하고 데이터크기가 1500이니 1500데이터를 전송을 했다. 수신측에서 제대로 받았다면 ACK를 통해 그 다음 시퀀스 번호인 1501를 전송하는 것이다. 만약 1500까지 보냈는데 ACK 번호가 갑자기 3001온다면 데이터 누락을 알아채고 재전송을 요청한다. TCP헤더에 시퀀스 번호 정보가 포함 된다. (데이터가 조각으로 분할 되어 있을때 시퀀스 번호 부여, 실제로는 위 그림처럼 1이 아닌 랜덤한 숫자로 부여함)

 

위 방식은 모든 프로토콜의 방식이 아닌 TCP 프로토콜의 예시 입니다.

3-WAY Handshake / 4-WAY Handshake 

 

애플리케이션이 프로토콜 스택으로 요청 -> 프로토콜 스택은 버퍼 메모리에 공간을 마련 -> connect를 통해 연결 -> write 에서 위와 같은 형식으로 데이터를 주고 받는다(TCP 방식)

 

만약 ACK 신호가 늦는다면?

ACK가 돌아오는 시간을 "타임아웃 값"이 부르며, 네트워크의 과부하로 인해 수신측으로부터 ACK가 돌아오기도 전에 송신측에서 못 받았다고 생각하고 다시 수신측으로 전송하면 문제가 발생 될 것이다. 이를 방지하기 위해 네트워크 상태를 확인 했다가 적절한 시간까지 기다렸다가 시간이 오버 되면 재전송을 하는 기능도 있다.

 

그럼 돌아오는  시간동안 네트워크는 가만히 있는가?

당연히 가만히 있지 않고 계속 다른 송/수신을 주고 받고 있다. 첫 번째의 송신처리가 다 끝나지도 않았는데 서로 다른 송신측으로부터 데이터를 계속 받다 보면 버퍼 메모리공간이 부족하게 되고, 데이터가 덮어짐으로써 데이터가 없어지면오류가 발생한다. 이를 방지하기 위해서 수신측에서 송신측으로 수신가능한 데이터의 양을 통지하고 수신측은 이 양이 초과하지 않게 송신 동작을 실행한다. 이것이 윈도우 제어 방식이다. 그리고 수신처리가 끝나면 TCP헤더의 윈도우 필드에 송신측에 알린다.

Ex) 이미 다른 송신측으로부터 통신을 이용하고 있다면 데이터 크기를 이미 파악을하고 여유분의 버퍼 공간을 두 번째 통신하는 송신측에 알려준다.

 

길고 길었던 과정이 끝났습니다.

지금까지 브라우저의 의뢰를 받아 프로토콜 스택이 HTTP 리퀘스트 메시지를 보내는 일련의 동작에 대한 설명이였습니다.

 

 

수신 데이터조각&TCP헤더 확인 -> 이상없으면 ACK 반송 -> 데이터조각 버퍼에 저장  조각을 연결하여 데이터의 본 모습으로 복원 후 애플리케이션 전송 -> 수신 데이터를 애플리케이션이 지정한 메모리에 기록 -> 애플리케이션에 데이터를 건네주고 타이밍을 가늠하여 윈도우를 송신측에 통지

 

 

다음글에서 계속......