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

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

 

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

 

 

---

chapter01에서는 애플리케이션 -> 프로토콜 스택 까지의 통신을 보았다.

 

 

chapter02에서는 프로토콜 스택 동작원리에 대해 좀 더 자세히 알아보고 요약을 하면 이렇다. 

 

1.소켓을 생성한다.

2.서버에 접속한다.

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

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

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

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

 

이번장에서는 OS에 내장된 네트워크 제어용 소프트웨어(프로토콜 스택)와 네트워크용 하드웨어(LAN 어댑터)가 브라우저에서 받은 메시지를 서버에 송출하는 동작을 설명.

 

 

 

 

---

1. 소켓을 생성한다.

 

서버와 애플리케이션의 중간다리인 소켓 생성을 보면 만드는건 Socket Library를 이용해서 간단히 만들수 있다. 소켓이 그럼 뭘 하는가??? 프로토콜 스택 내부에는 메모리 공간이 존재하는데 이곳에 통신 동작을 제어하는 정보가 있다. 이 정보를 기반으로 소켓과 접촉을 하는데 정보로는 IP주소, 포트 번호, 통신 동작 상태 등 정보가 담겨져있다. 소켓은 프로토콜 스택의 정보들을 가지고 통신을 계속 할 것인가 말것인가? 재전송을 할 것인가 판단을 해준다. 

 

 

 

애플리케이션이 소켓 호출 -> 프로토콜 스택은 메모리 영역 확보 -> 제어 정보를 메모리 영역에 기록한다. -> 처음 만들어진 상태 초기임을 알려준다. -> 소켓 생성 완료 -> 만들어진 소켓의 디스크립터를 애플리케이션에 알려준다.

 

 

 

---

2. 서버에 접속한다

 

 

이제 소켓을 생성했으니 연결을 할 차례이다 connect 하기 전까지는 프로토콜 스택은 메모리 영역만 확보를 한 상태이고 웹브라우저의 정보 (IP주소 + 포트번호 등) 가 없다. 그래서 connect를 이용 함으로써 웹브라우저에서 프로토콜 스택쪽으로 정보가 넘어가면서 통신이 가능하게 된다.

 

그럼 서버측은?

서버측도 소켓만 만들어진 상태이며 프로토콜스택에 정보가 없다. 더군다가 서버 애플리케이션에도 당연히 정보가 없기 때문에 클라이언트 에서 연결을 통해 서버측으로 전달을 한다.

 

 

서로 연결이 되면 이제 패킷을 주고 받는데 데이터 조각에 대해 설명을 하도록 하겠습니다.

[위 그림]을 참고를 하면 애플리케이션으로 내려오면서 하나씩 점점 붙어서 내려오는걸 알 수 있다. 복잡하니 다른부분 생략하고 간단히 설명을 하면 TCP/ UDP를 둘 중 하나 선택하고 IP로 순으로 밑으로 올 때 각 헤더파일을 추가가되서 밑으로 내려오게 된다. 헤더파일이란 각 프로토콜의 제어 정보이다. 

 

택배를 생각을 하면 상품이 있고, 상품 겉을 포장하고 완충제로 감싸고 박스에 넣고 주소를 적어서 보내듯이 포장, 완충제, 박스를 헤더 파일이라 생각을 하면 쉽게 이해 할 수 있다. 순차적으로 하나씩 과정을 거쳐야 하다고 생각!!

 

데이터를 받는 입장이면 각 헤더를 하나하나 까서 해당 명령에 맞게 수행을 하기 위해서이다. (Client A -> Client B 이동)

 

 

 

 connect 명령어를 사용하면 프로토콜 스택으로 부터 IP와 포트 번호가 TCP에 전달 되고 TCP는 서버의 TCP로 제어 정보를 주고 받는다. 이때 컨트롤 비트인 SYN, ACK를 통해 서로 통신이 가능한 상태임을 알려준다. 컨트롤 비트를 서로 주고 받았으면 비로소 송/수신을 할 수 있는 상태가 된다!

 

 

 

 

 

 

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