URI (Uniform Resource Identifier)
-
URI는 로케이터와 이름을 둘 다 추가로 해서 분류할 수 있다
- URL: Resource Locator -> 자원의 경로를 가리킴 (리소스의 위치를 지정)
- URN: Resource Name -> 자원의 이름을 가리킴 (리소스에 이름을 부여)
- 이름을 가리키면 이름에 매핑된 무언가... 가 있어야 하는데 그러기 어렵다.
- URN보다는 URL을 많이 쓴다.
-
URI:
-
Uniform 리소스를 식별하는 통일된 방식
-
Resource 자원, URI로 식별할 수 있는 모든 것
-
Identifier 다른 항목들과 구분하는 데 필요한 정보
-
위치는 변할 수 있지만 (URL), 이름은 변하지 않는다 (URN).
- URN (이름)만으로 실제 리소스를 찾는 방법이 보편화되지 않음.
- URI와 URL을 같은 의미로 사용하겠음 (!)
URL 문법
기본 문법: scheme://[userinfo@]host[:port][/path][?query][#fragment]
- 스키마: 주로 프로토콜 (https, http, ftp 등등), http는 80 포트, https는 443 포트를 주로 사용, 이 두 가지를 쓰면 포트는 생략할 수 있음 (http + Secure -> https)
- userinfo: URL에 사용자 정보를 포함해서 인정해야 할 때 쓰는데 현재는 거의 사용하지 않는다.
- host: 호스트명, 도메인 명, IP 주소를 직접 입력할 수 있음
- port: 생략 가능 (일반적으로는 생략)
- path: 리소스의 경로
- 보통 계층적 구조로 되어 있음
- query: key=value의 형태, ?로 시작, &로 추가 가능 (?keyA=value&keyB=valueB)
- query parameter (웹서버에 제공하는 파라미터), query string (문자 형태) 등으로 부름
- fragment: html 내부 북마크 등에 사용 (서버에 전송하는 정보 X)
웹 브라우저 요청 흐름
- URL로 요청을 보내면
(1) 웹 브라우저가 서버를 찾는다.- DNS 서버를 조회 -> IP를 확인
- 포트 정보 확인
- HTTP 요청 메세지 생성
- HTTP 요청 메세지가 포함하는 것:
GET (요청 방식) /path 이하의 url, HTTP 버전 정보, Host에 대한 정보 ... 등
(2) HTTP 요청 메세지 전송 - SOCKET 라이브러리를 통해서 전달 (호스트와 SYN/SYN+ACK/SYN)
- TCP/IP 패킷 생성 (HTTP 요청 메세지 포함)
(3) 인터넷 망으로 딱 던짐 -> 서버로 전달됨 - (서버가 하는 일) TCP/IP 패킷을 까서 버리고 HTTP 요청 메세지를 확인
(4) 서버가 HTTP 응답 메세지를 만들어 보낸다. - HTTP 응답 메세지가 포함하는 정보
- HTTP 버전, 200 OK (정상 응답)
- ContentType: 응답하는 데이터의 형식을 묘사
- ContentLength: 전송하는 데이터의 길이를 묘사
(5) 응답 메세지를 열면 HTTP 응답 메세지의 Content가 들어 있고, 요것을 (예시는 html) 렌더링해서 사용하게 된다.
