1. 인터넷 네트워크
1.1 IP
- 패킷을 만들어 던진다.
- 노드들을 거쳐서 목적지에 도달한다.
- 출발과 도착시에 거치는 노드는 상이할 수 있다.
- IP의 한계
- 비연결성
- 비신뢰성 : 중간에 패킷이 사라지면, 순서대로 안오면?
- 프로그램 구분
- 도착지가 서비스 불능일때도 패킷 전송되면?
- 중간 노드에서 처리중 오류나서 패킷이 소실되면?
- 패킷 전달 순서 문제 발생하면?(일반적으로 1500byte이상은 끊어 보낸다.)
1.2 TCP, UDP
인터넷 프로토콜의 4계층
- 애플리케이션 - HTTP, FTP
- 전송 - TCP, UDP (세그먼트)
- 인터넷 - IP (패킷)
- 네트워크 인터페이스 - 이더넷 (데이터프레임)
TCP/IP 패킷 정보
- Package(덩어리) + Bucket(박스) = Packet(패킷)
- IP 패킷은 출발지, 목적지 주소를 포함
- TCP 세그먼트는 포트정보, 전송제어, 순서제어, 검증 정보를 포함한다.
TCP 특징
- Transmission Control Protocol (전송 제어 프로토콜)
- 연결지향 (3way handshake)
- 가상연결(논리적으로)
- 중간의 노드는 알 수 없음
- 데이터 전달 보증 - 패킷 누락을 감지 가능
- 순서 보장
- 신뢰할 수 있는 프로토콜이므로 현재는 대부분 TCP를 사용한다
3way handshake
데이터 전달 보증
- 서버에서 답장을 받음
데이터 순서 보장
- 순서가 어긋날 경우 재전송 요청
UDP 특징
- 기능이 거의 없음
- 연결지향, 도착보증, 순서 보장 기능이 없다.
- 단순하고 빠르다. 3way handshake, 작은 세그먼트만 보냄, 최적화 하려면 UDP를 활용하면됨.
- IP와 거의 유사하지만 Port, Checksum 기능만 추가됨
- 최근에 http3에서 더 최적화 하기위해 udp를 사용하려고 하고 있음
1.3 PORT
한번에 둘 이상 연결해야 된다면?
- 온라인게임, 화상통화, 멜론 스트리밍 동시에 해야한다면?
- 같은 IP에서 프로세스를 구분하기 위한 번호가 포트번호
- TCP 패킷에 출발지와 목적지 포트번호가 명시되어 있음
포트번호
- 0~1023 : 잘 알려진 포트번호, 사용하지 말것
1.4 DNS
IP는 기억하기 어렵고, (자주) 변경될 수 있음
- 도메인 네임 시스템
- 전화번호부 같은 서비스
2. URI와 웹 브라우저 요청 흐름
2.1 URI(Uniform Resource Identifier)
-
URI, URL, URN ???
-
URI
- Uniform: 리소스 식별하는 통일된 방식
- Resource : 자원, URI로 식별 가능한 모든것
- Identifier : 다른 항목과 구분하는데 필요한 정보
- 최상위 개념, url + 쿼리스트링 까지 포괄
-
URL
- Locator 리소스가 있는 위치를 지정하는 것, 변할 수 있음
- "모스크바"
-
URN
- Name 리소스에 이름을 부여한 것, 변하지 않음
- 하지만 보편적으로 사용하지 않는다. 찾을가 없으니깐
- urn:isbn:8960777331
- "푸틴"
-
다라서 URI를 URL과 유사하게 활용함
URL
-
계층적으로 설계된다
-
scheme://[userinfo@]host[:port][?query][#fragment]
-
userinfo, port, query, fragment는 optional
-
Fragment는 html 내부 북마크 등에 사용됨
-
서버로 전송되지는 않음
2.2 웹브라우저 요청 흐름
-
DNS와 포트 조회
-
HTTP 요청 메시지 생성
-
소켓 라이브러리로 전달
-
TCP/IP로 3way handshake 함
-
TCP/IP 패킷 생성해서 그 안에 HTTP 메시지를 포함시킨다.
-
네트워크에 던지고, 서버에 패킷이 전달된다.
-
서버는 받은 패킷을 해석해서 HTTP메시지 추출
-
HTTP 응답 메시지를 생성한다. (이 중 Content-Type이 중요함)
-
응답메시지에 tcp/ip 씌워 전달한다.
-
응답메시지의 html을 브라우저가 해석하고 렌더링한다.
I'm going from failure to failure without losing enthusiasm