네트워크에 대하여 - 1

_1. 웹 통신의 큰 흐름: [https://www.google.com/](https://www.google.com/) 을 접속할 때 일어나는 일

 

 

1. www.google.com을  을 브라우저 검색창에 친다.

• 브라우저(Browser process안에있는 UI Thread)는 해당 검색어가 URL인지 검색어인지 확인 (handling inputs 과정)
  • 검색어 👉👉 search Engine으로 query 보내서 검색 준비
  • URL 👉👉 network thread로 URL 값 전달 준비

 

 

2. 브라우저는 캐싱된 DNS 기록들에서 www.google.com 에 대응되는 IP 주소가 있는지 확인한다.

1. 브라우저 캐시에서 DNS Query 실행
2. 브라우저가 OS 캐시 확인
   1. hosts 파일 확인
      • windows에서는 이 파일 내용 자체가 DNS cache에 포함되어있다고 함.
   2. DNS Cache Table 확인 (ipconfig/displaydns로 확인 가능)
      • 사용자가 DNS 서버에 질의하고 응답온 정보를 저장하는것 
3. router 캐시 확인 ( ex. 공유기 )
4. ISP 캐시 확인

 

 

3. 요청한 URL이 캐시에 없으면, IP 주소를 찾기 위해 DNS query를 날린다.

1. Recursive DNS Server ( Local DNS Server (기지국 DNS 서버) )
2. Root DNS Server
   1. TLD DNS 서버 주소만 관리! (ccTLD, gTLD, new gTLD, etc...)
   2. .com / .kr / .news 등 TLD DNS Server 주소를  ISP 서버에게  알려줌
3. Top-Level Domain DNS Server
   1. .com이라면 com TLD DNS Server에게 요청
   2. .naver.com을 확인한 후, naver Authoritative DNS Server 주소를 ISP 서버에 알려줌
4. Authoritative DNS Server
   1. .주소가 아직 남았다면 남은 주소를 찾아 ISP에 알려주고 반복
   2. naver.com이라면 해당 IP 주소를 ISP에게 알려주기
5. 알아낸 IP 주소를 브라우저에게 알려줌

 

4. 브라우저는 받은 IP 주소에 해당하는 서버와 인터넷 프로토콜 중 TCP를 사용하여 연결

• HTTP의 요청의 경우 일반적으로 TCP를 사용
• TCP/IP three-way handshake 라는 프로세스를 통해 클라이언트와 서버 간의 connection 이 이뤄짐!
  • 클라이언트 머신이 서버에 SYN 패킷을 보내고 connection 을 열어달라고 물어본다.
  • 서버가 새로운 connection 을 시작할 수 있는 포트가 있다면 SYN/ACK 패킷으로 대답을 한다.
    
  • 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 서버에게 ACK 패킷을 보낸다.

 

 

5. Browser가 웹 서버에 HTTP 프로토콜에 따른 요청을 한다. (데이터 전송)

• 클라이언트의 브라우저는 GET 방식으로 서버에 www.google.com 웹페이지를 요청한다.
• 요청 시 다른 부가적인 정보들도 함께 전달된다.
  
  • Accept 헤더 : 받아들이 요청의 종류
  • User-Agent 헤더 : browser identification
  • Connection 헤더 : 추가적 요청을 위해 TCP connection 유지를 요청
  • 브라우저에서 얻은 쿠키 정보 등

 

 

6 서버가 요청을 처리하고 Response를 생성한 후 응답한다

• 웹서버는 브라우저로부터 Request 받고 Request Handler에게 전달하여 Request를 읽고 Response를(http response) 생성하게 한다.

 

 

7 브라우저가 HTML content를 보여준다

1. 브라우저는 단계적으로 HTML content를 보여준다
2. HTML skeleton을 rendering한다
3. HTML tag들을 체크하고, GET 방식으로 추가적 웹페이지 정적인 요소들 (이미지, css stylesheet, javascript ..)을 요청한다.
4. 이 정적인 파일들은 브라우저에 의해 캐싱되어 나중에 해당 페이지 방문시 서버로부터 다시 불러오지 않도록 한다.
5. 결과적으로 www.google.com 의 모습이 보인다

 

 

 

 

 

- DNS 서버 종류

 

Root DNS Server: ICANN이 직접 관리하는 절대 존엄 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 함.

TLD(최상위 도메인) DNS Server: 도메인 등록 기관(Registry)이 관리하는 서버로, Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 함. 어떤 도메인 묶음이 어떤 Authoritative DNS Server에 속하는지 아는 이유는 도메인 판매 업체(Registrar)의 DNS 설정이 변경되면 도메인 등록 기관(Registry)으로 전달이 되기 때문임.

 

Authoritative DNS Server: 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버. 그래서 권한의 의미인 Authoritative가 붙음. 일반적으로 도메인/호스팅 업체의 ‘네임서버’를 말하지만, 개인 DNS 서버 구축을 한 경우에도 여기에 해당함.

Recursive DNS Server: 인터넷 사용자가 가장 먼저 접근하는 DNS 서버임. 위 3개의 DNS 서버를 매번 거친다면 효율이 구데기일 수밖에 없으니, 한 번 거친 후 얻은 데이터를 일정 기간(TTL/Time to Live) 동안 캐시라는 형태로 저장해 두는 서버임. 직접 도메인과 IP 주소의 관계를 기록/저장/변경하지는 않고 캐시만을 보관하기 때문에, Authoritative와 비교되는 의미로 반복의 Recursive가 붙음. 대표적인게 KT/LG/SK와 같은 ISP(통신사) DNS 서버가 있고, 브라우저 우회 용도로 많이 쓰는 구글 DNS, 클라우드플레어와 같은 Public DNS 서버가 있음.
얄딱구리한 구분으로 혼란스럽게 만드는 웹문서들이 많지만 DNS 서버는 모두 위 4가지 DNS 서버 종류 중 하나에 속함. 특히, 브라우저는 캐시가 저장된 Recursive 서버를 사용하고, 실제 네임서버를 설정하는 곳은 Authoritative 서버라는 점만 주의해서 이해하면 가장 좋을 듯함. 나머 두 서버는 컨트롤할 수 있는 영역도 아니고 언급되는 경우도 적으니 전반적인 이해를 위해서만 요런게 있네~ 정도로 생각하면 좋겠음.

 

---

_2. TCP와 UDP의 차이점에 대해서 설명해보세요.

 

# TCP, UDP

• TCP와 UDP는 OSI 7계층에서 전송 계층에서 사용하는, 데이터를 보내기 위해 사용하는 프로토콜

 

 

# TCP

• 인터넷 환경을 기본으로, 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜
  • IP : 데이터의 배달을 처리
  • TCP : 패킷을 추적 및 관리
• 특징
  1. 연결형 서비스로, 연결이 성공해야 통신가능
  2. 가상 회선 방식을 제공한다.
     • 발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정한다는 말
  3. 흐름 제어 및 혼잡 제어.
  4. 높은 신뢰성을 보장한다.
     • 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
  5. UDP보다 속도가 느리다.
     • 데이터 흐름-혼잡제어, handShaking 과정때문
  6. 전이중(Full-Duplex), 점대점(Point to Point) 방식.
     • 전이중 (Full-Duplex) - 전송이 양방향으로 동시에 일어날 수 있다.
     • 점대점 (Point to Point) - 각 연결이 정확히 2개의 종단점을 가지고 있다.

 

 

 

# UDP

• 데이터를 데이터그램 단위로 처리하는 프로토콜
• 특징
  1. 비연결형 서비스로 연결없이통신 가능
  2. 데이터그램 방식을 제공한다
  3. 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.
  4. UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다.
  5. 신뢰성이 낮다
  6. TCP보다 속도가 빠르다

 

 

 

 

 

 

 

 

Q) 흐름제어(Flow Control)와 혼잡제어(Congestion Control) 란?

 

흐름제어는 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것입니다. 예를 들어 송신하는 곳에서 감당이 안되게 데이터를 빠르게 많이 보내면 수신자에서 문제가 발생하기 때문입니다.

 

혼잡제어는 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것입니다. 만약 정보의 소통량이 과다하면

패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막습니다.

 

 

 

---

_3. TCP 3, 4 way handshake에 대해서 설명해보세요.

 

 

 

 

# TCP 3-way Handshake 란?

•  TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정
• 3번의 확인 과정을 거친다고 해서 3 way handshake

 

 

# TCP 3-way Handshake 과정

• 간단히 표현
  1. A -> B : 내 말 들려?
  2. B -> A : 잘 들려. 내 말은 들려?
  3. A -> B : 잘 들려!
• 자세한 내용
  1. A 👉 B : SYN
     • B서버에 접속을 요청하는 SYN 패킷을 보낸다.
     • 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 된다.
  2. B 👉 A : SYN + ACK
     • B서버는 SYN요청을 받고  A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다.
     • 이때 B서버는 SYN_RECEIVED 상태가 된다. 
  3. A 👉 B : ACK
     • A클라이언트는 B서버에게 ACK을 보내고 ESTABLISHED 상태가 됨. 이때의 B서버 상태가 ESTABLISHED 이다
     • 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다.

 

 

SYN (synchronize sequence numbers) - 연결 확인을 위해 보내는 무작위의 숫자값 (내 말 잘 들려?)

ACK (acknowledgements) - Client 혹은 Server로부터 받은 SYN에 1을 더해 SYN을 잘 받았다는 ACK (잘 들려)

ISN (Initial sequence numbers) - Client와 Server가 각각 처음으로 생성한 SYN (ACK+1)

 

 

 

 

# TCP 4-way Handshake 란?

• 수립된 TCP 세션을 종료하기 위해 수행되는 절차
• 4번의 확인 과정을 거친다고 해서 4 way handshake

 

 

 

# TCP 4-way Handshake 과정

• 간단 과정
  1. A -> B: 나는 다 보냈어. 이제 끊자!
  2. B -> A: 알겠어! 잠시만~
  3. B -> A: 나도 끊을게!
  4. A -> B: 알겠어!
• 자세한 과정
  1. A 👉 B : FIN
     • 클라이언트 👉👉 서버 :  연결을 종료하겠다는 FIN플래그를 전송한다. 
     • 이때 A클라이언트는  FIN-WAIT 상태가 된다.
  2. B 👉 A : ACK
     • B서버는 FIN플래그를 받고, 일단 확인메시지 ACK 보내고 자신의 통신이 끝날때까지 기다린다
     • 이 상태가 B서버의 CLOSE_WAIT상태다.
  3. B 👉 A : FIN
     • 서버가 연결을 종료할 준비가 되면, 연결해지를 위한 준비가 되었음을 알리기 위해 서버 👉👉  클라이언트에게 FIN플래그를 전송한다.
     • 이때 B서버의 상태는 LAST-ACK이다.
  4. A 👉 B : ACK
     • 클라이언트는 해지준비가 되었다는 FIN를 확인했다는 메시지 ACK 👉👉 서버에게 보낸다.
     • A클라이언트의 상태가 FIN-WAIT ->TIME-WAIT 으로 변경된다.

 

 

 

 

# Time-Wait

• 먼저 연결을 끊는 (active closer) 쪽에 생성되는 소켓으로, 혹시 모를 패킷 전송 실패에 대비하기 위하여 존재하는 소켓

 

 

 

# TIME-WAIT 상태가 존재하는 이유!

• 만약, Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황이 발생한다면??
  • 해당 데이터가 유실되어버리는 상황이 발생!
  • 👉👉 A클라이언트는 이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 합니다.
  • 일정시간이 지나면, 세션을 만료하고 연결을 종료시키며, "CLOSE" 상태로 변화

 

 

 

 

 

 

 

 

 

 

출처

https://velog.io/@guswns3371/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-httpswww.google.com-%EC%9D%84-%EC%A0%91%EC%86%8D%ED%95%A0-%EB%95%8C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC

[네트워크] https://www.google.com/ 을 접속할 때 일어나는 일

https://www.youtube.com/watch?v=ipwfEUslfQA 

https://babycoder05.tistory.com/entry/wwwgooglecom-%EC%9D%84-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-%EC%B9%98%EB%A9%B4-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EC%9D%BC-What-happens-when-type-wwwgooglecom

www.google.com 을 주소창에 치면 일어나는 일 (What happens when type www.google.com)

https://lecor.tistory.com/78

DNS 쿼리 처리 과정

https://library.gabia.com/contents/domain/713/

가비아 라이브러리

https://zzsza.github.io/development/2018/04/16/domain-name-system/

Domain Name System(DNS)의 이해

https://gentlysallim.com/dns%EB%9E%80-%EB%AD%90%EA%B3%A0-%EB%84%A4%EC%9E%84%EC%84%9C%EB%B2%84%EB%9E%80-%EB%AD%94%EC%A7%80-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC/

DNS란 뭐고, 네임서버란 뭔지 개념정리 | 살살살림

https://namu.wiki/w/DNS

DNS - 나무위키

https://hwan-shell.tistory.com/271?category=826872 

http와 tcp/ip의 이해

https://mangkyu.tistory.com/15

[TCP/UDP] TCP와 UDP의 특징과 차이

 

https://bangu4.tistory.com/74

[네트워크] 3-way / 4-way Handshake 란?

https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake

[ 네트워크 쉽게 이해하기 22편 ] TCP 3 Way-Handshake & 4 Way-Handshake

https://seongonion.tistory.com/74#TCP%---%--way%--handshake