2장. URL과 리소스
1. 인터넷 리소스 탐색하기
URL -> 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킴.
대부분의 URL은 동일하게 '스킴(어떻게)://호스트(어디에)/경로(무엇을)' 구조로 이루어져 있음.
2. URL 문법
URL로 인터넷 상 모든 리소스를 찾을 수 있지만,
각 리소스들은 다른 스킴(ex HTTP, FTP, SMTP)을 통해 접근할 수 있으며, URL 문법은 스킴에 따라 달라짐.
But 대부분의 URL은 일반 URL 문법을 따름!(서로 다른 URL 스킴도 형태와 문법 면에서 매우 유사)
-> <스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
당연히 모든 URL이 이 모든 컴포넌트를 가지지 x (스킴 , 호스트, 경로가 가장 중요한 컴포넌트!)
2-1) 스킴 : 사용할 프로토콜
-> 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보.
2-2) 호스트와 포트
애플리케이션이 인터넷에 있는 리소스를 찾으려면,
리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디 있는지 알아야 함.
-> URL 호스트와 포트 컴포넌트가 이 두 정보 제공!
* 포트 컴포넌트 : 서버가 열어놓은 네트워크 포트(HTTP는 기본 포트로 80 사용)
2-3) 사용자 이름과 비밀번호
많은 서버들은 자신이 가지고 있는 데이터에 접근 허용하기 전, 사용자 이름과 비밀번호를 요구.
2-4) 경로
리소스를 보관하는 호스트와 접근할 수 있는 서버를 찾았으니, 서버의 어디에 리소스가 있는지 알아야 함
-> 경로 컴포넌트가 이러한 정보 제공(즉 서버가 리소스의 위치를 찾는데 필요한 정보)
HTTP URL에서 경로 컴포넌트는 / 를 기준으로 경로 조각으로 나뉨 -> 각 경로 조각은 자체 파라미터 가질 수 o
2-5) 파라미터
But 많은 스킴이 이것만으로는 리소스 찾지 x! 더 많은 정보를 요구.
따라서 프로토콜 파라미터를 통해 리소스에 접근&요청 처리
-> 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는 데 사용!
EX) http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
-> 스킴(htttp)/호스트(www.~.com)/포트(80)/경로조각1(hammers);파라미터(sale)/경로조각2(index);파라미터(graphics)
2-6) 질의 문자열
데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해 질문이나 질의를 받을 수 o
(ex 해당 아이템이 존재하는지)
2-7) 프래그먼트
HTML 같은 리소스는 본래 수준보다 더 작게 나뉠 수 있음.
(ex 전체 HTML 중 하나의 문단만 가리키고자 할 때)
-> 리소스 내의 조각을 가리킬 수 있는 프레그먼트 컴포넌트 사용 - URL의 오른쪽에 # 문자에 이어서 옴
일반적으로 HTTP 서버는 객체의 전체만 다루기 때문에, 클라이언트는 서버에 프래그먼트는 전달 x
대신 브라우저가 서버로부터 전체 리소스를 내려받은 후 프래그먼트를 사용해 리소스의 일부를 보여줌.
3. 단축 URL
웹 클라이언트 -> 단축 URL 인식 및 사용 - 상대 URL 통해 리소스 안에 있는 리소스를 간결하게 기술 o
또한 URL 일부만 입력해도 나머지 부분 자동완성 o
3-1) 상대 URL
URL = 상대 URL & 절대 URL
지금까지는 모두 절대 URL -> 리소스에 접근하는데 필요한 모든 정보 가짐.
상대 URL -> 모든 정보 담고 있지는 x. 기저(base)라 불리는 다른 URL 사용해 리소스에 접근.
HTML에서 <a href = './hammers.html'> 요 녀석이 상대 URL!
이 경우 기저 URL은 http://www.joes-hardware.com/tools.html
href 클릭 시 새로운 절대 URL인 http://www.joes-hardware.com/hammers.html 로!
3-2) URL 확장
URL 입력 후나 도중 자동으로 URL을 확장!
크게 호스트 명 확장 / 히스토리 확장 으로 구분.
4. 안전하지 않은 문자
URL은 인터넷의 모든 리소스가 여러 프로토콜을 통해 전달될 수 있도록, 각 리소스에 유일한 이름 배정되게 제작.
-> 어떤 인터넷 프로토콜을 통해서도 안전하게 전송될 수 있도록 URL 설계하는 것이 중요!
따라서 모든 문자를 URL에 사용할 수는 x.
안전한 알파벳 이외 문자 사용 시 - 이스케이프 기능 사용해 인코딩할 수 있도록.
4-1) URL 문자 집합
-> US-ASCII 문자 집합 사용!
4-2) 인코딩 체계
안전하지 않은 문자?
-> % 기호로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 변환.
4-3) 문자 제한
% / . .. # ? ; : $ + @ & = 등이 미리 선점된 제한 문자.
-> 본래 목적 아닌 다른 용도로 사용하려면, 그전에 반드시 인코딩해야 함.
5. 스킴
http , https , mailto , ftp 와 같은 다양한 스킴 존재.
6. 한계와 개선
6-1) 한계
URL은 주소일 뿐, 실제 이름은 x!
즉 특정 시점에 어떤 것이 위치한 곳을 알려줌 -> 리소스가 옮겨지면 URL 사용 불가.
6-2) 개선
so 등장한 것이 -> URN
객체의 위치와 상관없이, 그 객체를 가리키는 실제 객체의 이름을 사용하는 방식!
이를 통해 리소스의 이름과 다른 몇 가지 정보만 있으면 위치가 바뀌더라도 위치를 찾을 수 있음
but URN 위한 표준화 및 주소 체계 변경 위한 작업량 어마무시 -> 당분간은 URL 여전히 사용될 것!
'source-code > software' 카테고리의 다른 글
GitHub 오류 모음 (1) | 2021.02.21 |
---|---|
GitHub 기본 명령어 익히기 (0) | 2021.02.20 |
HTTP 완벽 가이드 _ 3장 (0) | 2021.02.19 |
HTTP 완벽 가이드 _ 1장 (2) | 2021.02.18 |
AWS _ Route53 알아보기 (0) | 2021.01.09 |