인터넷 네트워크,인터넷 통신, IP(인터넷 프로토콜), TCP/UDP, PORT, DNS, URI와 웹 브라우저 요청 흐름

  출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식(유료) / 김영한님  
  유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용  

https://inf.run/8ZEU8

---

1. 인터넷 네트워크

• 인터넷 통신
• IP(Internet Protocol)
• TCP, UDP
• PORT
• DNS

1) 인터넷 통신

• 한국에서 미국으로 메시지를 보낸다고 가정했을 때 수많은 중간 노드라는 서버들을 거쳐서 넘어가게 됨

2) IP - 인터넷 프로토콜 

(1) IP의 역할

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

(2) IP 패킷 정보

• IP패킷 규칙에는 출발지 IP와 목적지 IP가 있어야 함

패킷 안에 데이터가 있음

 

(3) 클라이언트 패킷과 서버 패킷 전달 그림

• 패킷을 전송하면 노드서버들도 IP 프로토콜에 의해서 규약을 따르고 있어서 패킷 정보를 이해하고 도착지로 패킷을 전송
• 클라이언트가 서버로 보냈을 때의 노드 경로와 서버가 클라이언트로 보냈을 때의 경로는 다를 수 있음

좌) 클라이언트에서 패킷 전달 / 우) 서버에서 패킷 전달

 
 
(4) IP프로토콜의 한계

• 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송됨

서버의 컴퓨터가 꺼져있어도 패킷이 전송되어 패킷 정보가 소실 됨

 

• 비신뢰성 : 중간 노드 서버에 문제가 생겨 패킷이 소실될 수 있으며 패킷의 용량이 크면 나눠서 보내게 되는데(약 1500바이트 기준) 경로가 달라져 도착 순서도 달라질 수 있음

중간에 여러가지 사유로 노드 서버등에 문제가 생겨 패킷이 소실 될 수 있음

• 프로그램구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일때 구분할 수 없음

3) TCP / UDP

(1) 인터넷 프로토콜 스택의 4계층

• 애플리케이션 계층 - HTTP
• 전송 계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층 - 랜카드, 랜 드라이버 등등 

(2) TCP 프로토콜 계층

1. 프로그램이 전송할 데이터를 생성
2. SOCKET 라이브러리를 통해 OS에 전달
3. TCP 정보를 생성하여 데이터에 포함시킴
4. 해당 데이터(TCP정보가 있는)에 IP패킷을 생성
5. 네트워크 인터페이스를 통해서 Ethernet frame을 포함시켜서 전송 됨(MAC주소 같은 물리적인 정보들이 들어있음)

(3) TCP/IP 패킷 정보

• 패킷: 패키지(수화물) + 버킷(덩어리)의 합성어
• TCP 정보에 포트정보, 전송제어, 순서, 검증 등에 관련한 정보가 들어있음, IP만으로 해결이 안되었언 문제들이 해결 됨

 
(4-1) TCP의 특징

• 전송 제어 프로토콜(Transmission Control Protocol)
• 연결지향, TCP 3 way handshake(가상 연결)
• 데이터 전달과 순서를 보장
• 신뢰할 수 있는 프로토콜
• 현재 대부분 TCP 사용

(4-2) TCP 3 way handshake(가상 연결)

1. 클라이언트와 서버의 연결을 확인하기 위해 SYN(Synchronize)를 보냄
2. 서버에서 SYN을 받고 SYN과 ACK(확인)를 보냄
3. 클라이언트에서 ACK를 보냄 (최근에는 마지막 ACK를 보낼 때 데이터를 같이 전송할 수 있음)
4. 이 과정이 모두 성공하면 서버와 클라이언트가 연결이 되었다고 보고 데이터를 전송함
5. 중간의 수많은 서버들이 어떻게 연결 되어있는지는 알 수 없고 개념적으로 클라이언트랑 서버가 그냥 연결이 되었는 것만 확인 한 것

 

(4-3) 데이터 전달을 보증

• TCP가 붙게 되면 데이터 전송 되면 서버에서 데이터가 잘 전달이 되었다는 응답 메시지를 전달함
• 이런 응답 메시지로 데이터가 잘 전달 되었는지 인지할 수 있음

(4-4) 데이터의 순서를 보장

• 패킷이 클라이언트가 정한 순서대로 서버에 도착하지 않았을 때 순서가 잘못 된 패킷이후의 패킷은 전부 버리고 다시 보내라는 요청을 함
• 클라이언트가 요청을 받고 잘못된 순서부터 다시 데이터를 전송함
• 내부적인 최적화 동작에 따라 다르지만 기본적으로는 이렇게 동작함

 
(5) UDP의 특징

• 사용자 데이터그램 프로토콜(User Datagram Protocol)
• 하얀 도화지에 비유(기능이 거의 없음)
• TCP가 제공하는 연결지향, 데이터 전달 보증, 순서보장이 모두 없음
• 데이터 전달 및 순서가 보장되지 않지만 단순하고 빠름
• IP와 거의 비슷하며 포트(패킷을 구분)와 체크섬(데이터의 검증) 정도만 추가 됨
• 애플리케이션에서 추가 작업이 필요함

(6) UDP의 장점

• TCP는 데이터양도 크고 전송속도도 느리고 이미 구축이 다 되어있어서 최적화를 더이상 할 수 없음
• UDP는 아무것도 없기 때문에 직접 애플리케이션레벨에서 최적화를 할 수 있음
• 거의 대부분 90%이상 TCP프로토콜을 쓰지만 최근에는 HTTP3 스펙이 나오면서 더 최적화를 하며 UDP가 뜨고있음

4) 포트(PORT)

(1) 한번에 둘 이상 연결 해야 할 때

• 같은 IP 내에서 프로세스를 구분 할 때 포트 정보를 이용함
• TCP 패킷 정보에 출발지 ip와 port, 도착지 ip와 port의 정보가 함께 있어서 해당 포트들로 데이터를 전송
• 아파트(서버, 클라이언트 등)의 몇동 몇호(포트) 정도로 이해하면 좋음

좌) 포트 정보가 없는 그림 / 우) 포트 정보가 표시 된 그림

(2) 포트넘버

• 0 ~ 65535 까지 할당 가능
• 0 ~ 1023 : 잘 알려진 포트 (사용하지 않는 것이 좋음)
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

5) DNS

(1) DNS - 도메인 네임 시스템(Domain Name System)

• IP는 기억하기 어렵고, 변경 될 수 있음 -> DNS로 해결
• DNS서버에 도메인(도메인은 구매 해야함)과 IP를 등록
• 클라이언트가 DNS서버에 도메인으로 요청하면 DNS서버에 등록된 IP로 응답을 주고 클라이언트는 응답받은 IP로 서버에 접근함

---

2. URI와 웹 브라우저 요청 흐름

1) URI, URL(주로 사용), URN

좌) URI, URL, URN의 구분 / 우) URL과 URN의 비교

(1) URI - Uniform Resource Identifier

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier : 다른 항목과 구분하는데 필요한 정보
• 로케이터(locator) 이름(name) 또는 둘 다 추가로 분류 될 수 있음
• https://www.ietf.org/rfc/rfc3986.txt - 1.1.3. URI, URL, and URN / 표준 스펙

(2) URL, URN

• URL - Locator : 리소스가 있는 위치를 지정
• URN - Name : 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않음
• URN이름 만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되어 있지 않음

2) URL분석

(1) URL 전체 문법

scheme://[userinfo@]host[:port][/path][?query][#fragment]
scheme://	[userinfo@]	host	[:port]	[/path]	[?query]	[#fragment]
https	별도설명	www.google.com	443	/search	?q=hello&hl=ko	별도설명
https://www.google.com:443/search?q=hello&hl=ko

 

(2) 구성

• 프로토콜 : https
• 호스트명 : www.google.com
• 포트번호 : 443
• 패스 : /search
• 쿼리 파라미터 : q=hello&hl=ko

(3) scheme

• 주로 프로토콜을 사용
• 프로토콜: 자원에 어떤 방식으로 접근할 것인가를 정한 약속, 규칙
• ex) http, https, ftp 등등
• http는 80 포트, https는 443포트를 주로 사용 (포트는 생략 가능)
• https는 http에 보안이 추가 된 것(HTTP secure), 현재 대부분의 웹사이트는 https를 사용함

(4) userinfo

• 거의 사용하지 않으며 URL에 사용자 정보를 포함해서 인증

(5) host

• 호스트명
• 도메인명 또는 IP 주소를 직접 사용 가능

(6) port

• 접속 포트
• 일반적으로 생략

(7) path

• 리소스의 경로(path), 계층적 구조
• ex) ~/members/100 , ~ /items/iphone12 등..

(8) query

• key=value 형태
• ?로 시작, &로 추가 가능 (?keyA=valueA&keyB=valueB)
• query parameter(웹 서버에 제공하는 파라미터 정보), query string(숫자를 적어도 모두 문자로 넘어감) 등으로 불림

(9) fragment

• https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-introducing-spring-boot
• html 내부 북마크 등에 사용
• 서버에 전송되는 정보는 아님

3) 웹 브라우저 요청 흐름

(1) 웹 브라우저에서 구글 서버로 요청을 전송

(2) DNS를 조회하여 IP와 포트정보를 찾고 HTTP요청 메시지를 생성

좌) DNS를 조회하여 IP와 포트를 찾아 HTTP 요청 메시지를 생성 / 우) HTTP 요청메시지의 예시

 

(3) 생성한 HTTP 메시지를 SOCKET 라이브러리를 통해 OS에 전달하고 TCP/IP 패킷을 생성(메시지 포함)하여 서버로 전송

좌) HTTP 메시지가 보내지는 전체적인 프로세스 / 중) TCP/IP 패킷, / 우)TCP/IP패킷 + HTTP메시지

 

(4) 요청 패킷을 구글 서버로 전달하면 구글 서버가 도착한 패킷의 메시지를 분석하여 데이터를 찾음

 

(5) 구글 서버에서 HTTP 응답 메시지를 만들어서 브라우저에게 전달

• HTTP버전과 응답정보
• Content-Type : 응답 형식(html)과 언어(UTF-8)
• Content-Length : 실제 데이터의 길이

좌) HTTP 응답 메시지 예시 / 우) 구글 서버에서 응답 패킷을 웹 브라우저에 전달

 

(6) 도착한 응답 패킷의 메시지를 분석하여 웹 브라우저가 HTML을 렌더링 하여 화면에 출력

좌) 웹 브라우저가 응답 패킷을 분석 / 우) 최종 출력