1. 내가 브라우저를 클릭 : 내 컴퓨터(OS가) 브라우저 Process를 시작
윈도우 커널이 브라우저 스크립트를 로드, 메모리에 올림
브라우저 Process 생성 Main() 함수 호출(브라우저 프로그램 시작)
2. 브라우저의 네트워크 I/O 초기화
브라우저 Process의 Main() 내부에서 네트워크 서브 시스템을 초기화한다.
이제부터, 네트워크 영역의 I/O(네트워크 I/O)의 시작이다.
어플리케이션 영역에서 아래 계층으로 내려간다.
3. DHCP 프로토콜의 동작
DHCP란 내 컴퓨터(호스트)가 네트워크에 접속할 때, 자동으로 IP 주소 및 네트워크 설정 정보를 할당받도록 하는 프로토콜이다.
**주의할 점은 ARP와 DHCP는 다르다는 것이다.**
**DHCP의 주 관심사는 IP의 할당이다.**
**DHCP에서 내 컴퓨터와 가정용 공유기는 자동으로 MAC을 학습해 ARP 캐시에 저장할 뿐이다.(겸사 겸사란 말이 어울린다.)**
**이때, ARP 캐시에 정상적으로 저장되지 않았을 때, ARP가 실행되는 것.**
**즉, DHCP의 주관심사 = IP, ARP의 주 관심사 = MAC**
3-1. 내 컴퓨터 OS 라우터가 어뎁터 MAC 주소를 포함한 DHCP 메시지를 브로드캐스팅 하다.
이런 식의 메시지를 서브넷들(LAN)에 브로드 캐스팅한다.
Src MAC : 내 컴퓨터의 MAC 주소이다.
Src IP : 내 컴퓨터의 IP 주소이다. 첫 연결이기 때문에 아직 IP 할당이 되어있지 않다.
**브로드 캐스팅은 MAC 주소가 FF:FF:FF:FF:FF:FF로 되는 것 같다.(뭐, 그리 중요한....가?)
3-2. LAN에 브로드 캐스팅된 메시지를 가정용 공유기가 받아 응답한다.
브로드 캐스팅된 위의 메시지를 가정용 공유기가 받는다.
가정용 공유기는 DHCP 서버라고 볼 수 있다.
이 가정용 공유기(DHCP 서버)는 브로드 캐스팅 된 메시지에서 Src MAC 주소(AA)를 받아 ARP 캐시에 저장해둔다.
그 후, 내 컴퓨터의 IP 주소를 CIDR 방식으로 할당한다.(이외에도 여러 할당하는 정보가 존재한다. 생략한다.)
그렇게 할당된 IP 주소를 담아 다시 내 컴퓨터로 응답해준다.
3-3. 내 컴퓨터가 IP 주소를 할당받다.
가정용 공유기(DHCP 서버)에서 "내 컴퓨터에 IP 주소를 포함한 이런저런 설정들을 내가 해줬어! 적용해!"라는 메시지를 보냈다.
내 컴퓨터는 Src MAC을 ARP 캐시에 저장하고(이후에 ARP를 안하고, 가정용 공유기로 찾아가기 위함), 할당해준 내 컴퓨터의 IP 주소를 설정하는 등 여러 작업을 한다.
이제, 내 컴퓨터는 가정용 공유기(DHCP 서버)의 MAC 주소(Src MAC)와, IP 주소(Src IP)를 알고 있다.(위 그림)
3-4. 내 컴퓨터가 이 설정을 쓰겠다는 확정 요청을보내다.
뭐든 상대가 일을 해줬으면, 확인 메시지와 감사하다는 응답을 해주어야한다. 내 컴퓨터는 올바른 심성을 가진 아이이기 때문에, 역시 응답을 보낸다.
내 컴퓨터는 이제 가정 공유기 MAC 주소를 알고 있으니 콕 찝어서 유니 케스트로 보낸다.
3-5. 가정용 공유기(DHCP 서버)가 "유아웰컴"을 보내다.
가정용 공유기도 이제 내 MAC 주소를 알고 있으니, 콕 찝어서 유니 케스트로 보낸다.
4. 내 컴퓨터의 브라우저 Process에서 www.naver.com로 접속을 시도하다.
4-1. 아직, 한발 남았다. DNS 프로토콜의 시작
내 컴퓨터는 TCP를 생성하기 위해서는 "www.naver.com"의 IP를 알아야 한다.
DNS에 " "www.naver.com" 의 IP가 뭔가?"라는 메시지를 보내야겠지?
보낸다.
4-2. DHCP에서 학습한 가정용 공유기의 IP로 질의 메시지를 보낸다.
위와 같은 질의 메시지를 보낸다.
만약, DHCP로 MAC이 학습되어있지 않았다면, ARP를 수행 후, MAC을 학습한 뒤 보낸다.
4-3. 가정용 라우터에서 "www.naver.com"이라는 도메인에 매핑되는 IP를 받아온다.
TCP 공부 후 계속
5. 3-Way-HandShake
컴퓨터의 브라우저 Process는 connect(IP, TCP)를 호출한다.
이제서야, TCP 연결을 시도한다.
내 컴퓨터의 OS 커널 ARP 캐시에는 공유기 MAC 주소가 있으니, 바로 3-Way-HandShake 요청을 보낼 수 있다.
보낸다. syn
1-7-9. 내 컴퓨터 IP를 담아, 네이버의 IP에 요청을 보낸다.
이제, 가정 공유기로 내 컴퓨터 IP를 네이버의 IP로 보내줘야 한다.
뭐, 역시 여러 계층들을 거치며, 패킷, 세그, 데이타그램...여러가지로 바꾼 뒤 보내준다.
1-7-10. NAT 적용 WAN의 영역으로...
현재, 3-way-handshake의 요청에는 내 컴퓨터 IP(192.xxx.xxx.xx)와 네이버 퍼블릭 라우터 IP가 들어있을 것이다.
내 컴퓨터 IP를 가진 요청에는 NAT이 적용되어, 가정 공유기의 IP가 들어가게 된다.
즉, {192.xxx.xxx.xx + 네이버 퍼블릭 라우터 IP}라는 요청이 {203.xxx.xxx.xx + 네이버 퍼블릭 라우터 IP}라는 요청으로 NAT 적용 변환된다.
이 요청을 가정 공유기가 WAN의 영역으로 전송한다.
이제부터 내 서브넷의 어뎁터 MAC 주소는 필요 읎다.
다음 홉(WAN의 라우터)의 MAC 주소를 위해 ARP를 수행할 뿐...(PPPoE 세션 맺기 등을 수행하긴 하는데, 이것도 추상화해서 WAN에서 링크들이 되는구나~하고 넘어가자.)
1-7-11. 3-way-handshake 편지를 데이터 센타 라우터가 받다.
**여기서 Spine/Core, 3-tier 등등 라우팅 방식이 활용될 수 있겠다.**
**여기도 그냥 추상화 해서 넘어가자**
**위의 그림은 “Collapsed Core” 또는 “Flat Topology” 라고 한다. GPT 피셜**
**나중에, 여러 로드벨런싱 구조를 공부해보면 될 듯하다.**
여러 라우터를 지나, 간신히 퍼블릭 라우터의 인터페이스로 내 컴퓨터가 보낸 핸드셰이크 요청이 도착했다.
이제부터 네이버의 웹 서버는 수신자의 역할을 수행해야한다.(이제부터 LAN의 영역이다.)
물리-> 링크 계층까지 도달했으면 이제 뭘해야하는가?
데이터 센터 라우터로다가 이 요청을 보내줘야겠다.
그럼 뭘 해야 하는가?
데이타 센타 라우타의 MAC 주소를 알아야하지 않겠는가?
그렇다. 데이터 센타의 라우터는 ARP를 시도한다.
1-7-12. 데이타 센타 라우터의 ARP로 웹 서버의 MAC 주소 알아오기
데이타 센타 라우타는 우리가 보낸 {가정공유기 IP + 퍼블릭 라우터 IP}를 받는다.
젠장... 아직 갈 길이 멀다.
퍼블릭 라우터는 다시 링크 계층까지 올라와, ARP를 시도한다.(첫 시도일 시)
서브넷의 여러 데이타 센타 라우타의 MAC 주소 중 하나를 ARP로 캐싱해둔다.
이제, 다음 요청부터는 캐싱해둔 MAC 주소로 링크 계층 스위치가 알아서 보내줄 것이다.
=> 잠깐 드는 생각인데, 고 트래픽 상황을 대비하여, 미리 여러 데이타 센타의 MAC 주소를 캐싱해둬야할 것 같다.
=> 아니면, 정적 ARP로 캐싱을 아예 박아두던가...
1-7-13. 웹 서버까지로 도달하다.
데이터 센터 라우터의 MAC주소로 내 컴퓨터가 보낸 요청을 보낸다.
데이터 센터 라우터는 위의 ARP를 또 거친 후 결국, 웹 서버로 내 요청을 보낸다.
웹 서버는 이를 받고, 전송 계층까지 올라와, ACK + SYN을 보내줘야겠지?
응답을 보낸다.
1-7-14. SYN이 내 컴퓨터로 도달하다.
너무 길다. 생략 좀 하겠다.
그렇다. 이렇게 내 컴퓨터까지 ACK + SYN이 도달했다.
ㄷㅏ시, ACK를 서버까지 보내준다.
1-7-15. 3-way-handshake로 TCP 연결이 생성되다.
그렇다. 이렇게 TCP 연결이 생성되었다.
이제, 웹 서버는 HTTP로 네이버의 여러 정보들을 REST하게 보내줄 것이다.
1-7-16. TCP로 통신하다.
위의 과정들과 비슷하게 TCP로 HTTP 메세지들을 송신, 수신한다.
