인터넷의 리소스 탐색하기
URI (Uniform Resource Identifier)는 URL과 URN의 합집합이다.
URN : 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별
URL : 리소스가 어디 있는지 설명해서 리소스를 식별
scheme : 웹 클라이언트(브라우저...?)가 리소스에 어떻게 접근하는지 알려줌
domain name : 서버의 위치, 웹 클라이언트가 리소스가 어디에 호스팅 되어있는지 알려줌
path : 리소스의 경로. 서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려줌
scheme는 ftp, rtsp 등 다양하다
URL이 있기 전 암흑의 시대
URL이 있기 전에 complete-catalog.xls라는 파일을 공유하려고 했다면?
ftp.ybm1234.tistory.com에 ftp로 접속 -> 로그인 -> 디렉토리 이동 -> 바이너리형식으로 전환 후 complete-catalog.xls파일을 로컬 파일에 다운
이 복잡한 과정을 거쳐야했다.
하지만 지금은 ftp://ftp.ybm1234.tistory.com/complete-catalog.xls에 접속해서 다운받으면 된다.
URL은 브라우저에게 정보를 찾는데 필요한 모든 것을 제공하며, 원하는 리소스가 어디에 위치하고 어떻게 가져오는지 정의한다.
URL 문법
스킴에 따라 다른 문법이 필요하지만 형태와 문법은 유사하다.
anchor (프래그먼트) : 리소스의 조각이나 일부분을 가리키는 이름, 같은 페이지에서 특정 위치로 이동할때 사용했되는...
스킴: 사용할 프로토콜
주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보
호스트와 포트
호스트 : 접근하려고 하는 리소스를 갖고 있는 호슽스트 장비
포트 : 서버가 열어놓은 네트워크 포트, 내부적으로 TCP프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용한다.
사용자 이름과 비밀번호
ftp://ftp.prep.ai.mit.ecu/pub/gnu
사용자 이름/비밀번호가 없다.
서버가 요구하는 이름/비밀번호가 없을때 이름은 anonymous로 비밀번호는 브라우저마다 갖고있는 기본 값을 사용한다 (ie: IEUser, chrome: chrome@example.com)
경로(path)
리소스가 서버의 어느 위치에 저장되어있는지 알려준다
파라미터
위의 그림에는 없지만
.../경로;파라미터?질의#프래그먼트
요렇게 들어간다
바이너리와 텍스트 2개의 포맷을 지원하는 ftp가 있다면 무엇을 선택해야하는지 지정해 줘야한다.
URL의 파라미터는 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용한다.
key/value 쌍의 리스트로 구성되어있고 URL나머지 부분들로부터 ;(세미콜론)문자로 구분된다.
ftp://ybm1234.tistory.com/pub/gnu;type=d
요런 식이다
질의 문자열 (query)
데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질의를 받을 수 있다.
프래그먼트
프래그먼트는 서버로 보내지 않고 리소스를 반환 후에 브러우저가 프래그먼트로 시작하는 페이지나 부분을 찾아서 보여준다
단축 URL
상대 URL
기저 URL (base url)
어떻게 Base URL을 찾을 수 있나?
- 리스소에서 명시적으로 제공 : html문서에서 base url을 가리키는 <base> html 를 기술할 수 있다.
- 리소스를 포함하고 있는 기저 URL : url이 명시되지 않은 리소스에 포함된 경우 해당 리소스의 url을 base url로 사용할 수 있다 (대부분 이 방식이 아닐까...?)
- base url이 없는 경우 : 이 경우 모두 절대 URL로만 이루어져있다는 뜻
상대 참조 해석하기
URL 확장
브라우저 주소 area에 검색하면 나오는 기능을 말하는 듯
호스트 명 확장 : yahoo를 검색하면 앞에 www. 뒤에 .com을 붙여주는 식으로 확장
히스토리 확장 : 방문했던 url기록 중 검색 글자를 포함하는 url을 선태갛게 해줌
안전하지 않은 문자
안전한 전송이란 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다.
SMTP(Simple Mail Transfer Protocol)같은 프로토콜은 특정 문자를 제거할 수도 있는 전송방식을 사용한다 (7비트 인코딩을 사용하기 때문에 8비트 이상으로 인코딩되어 있으면 정보가 소실된다) 문자가 제거되는 일을 피하고자 URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락한다. 인쇄되지 않는 문자(공백)은 포함할 수 없다.
URL 문자 집합
역사적으로 많은 컴퓨터 애플리케이션이 US-ASCII를 사용해왔고 이게 7비트다. 자판에 있는 키 대부분과 몇몇 출력되지 않는 제어문자를 표현한다.
US-ASCII외의 문자나 특정 이진데이터를 포함해야하는 경우가 있어서 URL에 escape문자열을 쓸 수 있게 설계하였다.
escape문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.
인코딩 체계
문자 제한
%, @, &, <> 등의 문자열이 url 문법에 사용되거나 안전하기 않기 때문에 사용이 제한된다.
스킴의 바다
미래
URL이 완벽한건 아니다. 실제 같은 페이지가 옮겨진다면 URL로 찾아올 방법이 없다.결국 객체를 가리키는 실제 객체의 이름을 사용해야 한다. Internal Engineering Task Force는 이를 해결하기 위해 URL(Uniform Resource Names)라는 새로운 표준 작업에 착수했다. 객체가 옮겨지더라도 항상 객체를 가리킬 수 있는 이름을 제공한다.
'HTTP완벽 가이드' 카테고리의 다른 글
5. 웹 서버 (0) | 2021.03.31 |
---|---|
3. HTTP 메시지 (0) | 2021.03.17 |
1장 HTTP 개관 (0) | 2021.03.03 |