URI (Uniform Resource Identifier)

URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다

💡 URL은 리소스의 위치를 나타내고 URN은 리소스 그 자체의 이름을 말함.
URI는 이 둘을 포함하는 가장 큰 개념

URN만으로는 리소스에 접근할 수 있는 방법이 보편화 되어있지 않아서 URL만 사용한다고 생각해도 좋다

URI의 뜻

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것을 말함
• Identifier : 다른 항목과 구분하는 데 필요한 정보. 식별자

URL, URN

• URL - Locator : 리소스가 있는 위치를 지정
• URN - Name : 리소스에 이름을 부여
• 위치는 변할 수 있지만 이름은 변하지 않음
• 하지만 URN 이름만으로는 실제 리소스를 찾을 수 있는 방법이 보편화 되어 있지 않음.
• 따라서 URI 와 URL을 거의 같은 의미로 생각해도 됨

URL 분석

scheme://[userinfo@]host[:port][/path][?query][#fragment]

scheme

• 주로 프로토콜이 사용됨
• 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
  • ex ) http, https, ftp 등
• http는 80 포트, https는 443 포트를 주로 사용하고, 포트는 생략할 수 있음

userinfo

• 거의 사용하지 않음

host

• 도메인명 또는 IP 주소를 직접 사용할 수 있음

port

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

path

• 리소스 경로
• 계층적 구조로 되어있음

query

• key=value 형태로 되어있음
• ?로 시작하고 &로 추가함
• query parameter, query string 등으로 불림 (웹서버에 제공하는 파라미터라서)
• 모두 문자 형태로 서버로 전송됨

fragment

• html 내부 북마크 등에 사용되고, 서버에 전송되는 정보는 아님

웹 브라우저 요청 흐름

주소창에 url을 입력했을 때의 흐름

1. DNS 조회해서 IP 정보를 가져오고, 포트 정보도 확인 (생략 시 기본 포트)
2. 웹 브라우저가 HTTP 요청 메세지를 생성
3. SOCKET 라이브러리를 통해 전달
   1. TCP/IP 연결 (3 way handshake)
   2. 데이터 전달
4. TCP/IP 패킷 생성, HTTP 메시지도 포함되어있음
5. 요청 패킷을 서버에 전달
6. 서버에서는 HTTP 메시지를 해석해서 HTTP 응답 메시지를 클라이언트에게 전달
7. 클라이언트에서는 받은 응답 메시지로 브라우저에 렌더링을 함

💡 **3 way handshake가 발생하는 시점**
애플리케이션 계층에서 Socket 라이브러리를 통해 TCP 계층으로 데이터를 전달할 때,
Socket 라이브러리가 커넥션을 TCP/IP로 맺으라고 전달하면 
그 하부에서(TCP 계층) 3 way handshake를 실행하고 연결이 됨.
즉, Socket 라이브러리는 TCP 계층에서 3 way handshake 작업이 일어나도록 
실행을 해주는 역할을 한다고 생각하면 된다.

💡 3 way handshake도 마찬가지로 이를 위한 신호 정보가 패킷에 담겨서 
물리 계층을 통해 전달이 됨.
HTTP 메시지가 포함된 패킷이 전달되기 전에 
연결을 위한 패킷이 먼저 왔다 갔다 하고, 연결이 확인되면 요청 패킷이 전달됨

💡 3 way handshake는 클라이언트와 서버가 서로 연결을 맺는 과정이고 
클라이언트와 서버 사이에서 한번만 발생함.

흐름 디테일

우리가 어떤 URL을 입력하게 되면 (www.example.com)우선 DNS에서 이 URL에 해당하는 IP 주소를 획득해야 함.
이때 사용자가 위치에서 가장 가까운 DNS(로컬 DNS)에 IP주소를 질의(query)하게 됨.
로컬 DNS내부에 해당 URL이 매칭되는 IP주소가 캐싱되어 있지 않다면 로컬 DNS는 루트 DNS로 IP주소를 질의함.
루트 DNS 에서도 www.example.com을 알지 못하기에 .com을 관리하는 DNS의 주소를 알려줌.
그러면 로컬 DNS는 .com을 관리하는 DNS 서버로 가서 www.example.com을 질의함.
이런식으로 최종 IP 주소를 알아낼 때까지 질의를 반복 (이를 DNS iterative query 라고 함)

이제 아이피 주소를 발견하게 되면 SYN 신호를 해당 아이피로 보냄.
이를 받은 서버는 SYN+ACK 신호를 보내게 되고, 클라이언트가 최종 ACK 신호를 보내며 3-way handshake를 하게 됨.
웹 초창기에는 모든 데이터에 이 3-way handshake를 해야 했기에 효율이 매우 나빴는데,
HTTP/1.1 부터는 'HTTP 지속 연결 상태'(persistence connection) 이라는 개념을 도입, 모든 바이트에 3-way handshake를 하는 것이 아니라 최초에 handshake를 하고 이후에는 계속 연결을 유지하는 방식을 도입.
모든 연결이 끝났을 때 헤더에 연결 종료를 알림으로써 TCP 연결을 끊는 식.

이 HTTP 지속 연결 상태를 기반으로 HTTP 파이프라이닝 이라는 기술도 같이 적용됨.
이는 한번 연결된 TCP 연결을 기반으로 여러 개의 요청을 '병렬' 요청함으로써 FIFO 방식 처리의 단점인 지연(latency) 문제를 해결.

이후 HTTP/2.0 에서는 최초 TCP 연결 이후 스트림(stream) 방식으로 여러 요청을 처리하는 멀티플렉싱 기능을 도입하여 더욱 속도 향상을 이루었고, HTTP/3.0에서는 아예 TCP가 아닌 UDP 방식으로 데이터를 전송함으로써 3-way handshake를 아예 하지 않아도 되는 식으로 발전하고 있음.