들어가기 ) URL을 왜 사용하는가?

인터넷🌍 = 거대한 도시라고 가정해보자.

우리는 도시의 수많은 볼거리와 서비스들을 지칭하는 ‘표준 작명 프로토콜’을 사용하기로 한 것이다.

• 박물관, 레스토랑, 주택을 설명하기 위해 ‘길거리 주소’📭를 사용함
• 다른 사람에게 연락하기 위해 ‘전화번호’☎ 사용함

리소스들은 적절히 분류되기 위해 각자 저만의 표준화된 이름을 가진다.

• 책들은 책 분야, 내용에 따라 ISBN 번호로 분류됨📚.
• 버스는 노선에 따라 노선번호를 가짐🚌.
• 은행 계좌는 계좌번호를 가짐💳
• 사람들은 사회보장번호(주민등록번호)👩를 가짐.

이렇게 표준화된 이름이 다양한 리소스에 정해져 있고,
우리가 그것에 동의하여 사용하고 있기 때문에
우리는 소중한 리소스들을 모두 쉽게 공유할 수 있으며, 의사소통을 쉽게 할 수 있다.

EX) 택시기사에게 “관악구 관악로 1 - 64동으로 가주세요”라고 말하면 어느 곳을 말하는지 안다. 최소 내비게이션은 안다..

URL(Uniform Resource Locator)은 인터넷 리소스를 가리키는 표준 이름이다.
그것이 어디에 있으며, 어떻게 접근할 수 있는지를 알려준다.

인터넷의 리소스를 탐색하는 URL

---

1. URL은...

브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킨다. ⇒ (Locator)

덕분에, 사람과 애플리케이션이 인터넷 상의 수십 억 개의 리소스를 찾고 사용하며 공유할 수 있다.

사용자가 브라우저에 URL을 입력하면, 브라우저는 사용자가 원하는 리소스를 얻기 위해 적절한 프로토콜을 사용하여 메시지를 전송한다. (사용하는 프로토콜은 URL에 명시되어있다-가장 앞 부분)

대단한 그림판 실력ㅋ

URL은 URI(Unifrom Resource Identifier, 통합 자원 식별자)라고 불리는 더 상위 개념의 부분집합이다.

URI는 URL, URN을 포함하는 개념이다. 참고로 URL은 위치를 통해 자원을 식별하고, URN은 고유한 이름을 통해 자원을 식별한다.

2. URL의 구조

예시 url

http://www.joes-hardware.com/seasonal/index-fall.html
이라는 url을 불러오고 싶다고 해보자.

• URL 첫 부분인 http 는 URL의 스킴이다. 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다. 이 경우, ‘HTTP 프로토콜’을 사용하여 접근한다.
• URL 두 번째 부분 www.joes-hardware.com은 서버의 위치를 알려준다. 리소스가 어디에 호스팅이 되어있는지 알려주는 것.
• URL 세 번째 부분 /seasonal/index-fall.html 은 리소스의 경로다. 서버에 존재하는 로컬 리소스들 중 요청받은 리소스가 무엇인지 알려주는 것.
• 스킴 : 어떻게(리소스에 어떻게 접근), 호스트: 어디에(리소스가 어디에) 경로: 무엇을(어떤 리소스를)
  

⇒ 즉 URL은 브라우저, 컴퓨터, 서버, 서버파일 시스템의 어디에 위치하고 어떻게 연결되는지 보여준다.

3. HTTP가 아닌 다른 프로토콜

mailto:president@whitehouse.gov
mailto는 이메일 주소를 가리킴

[ftp://ftp.lots-o-books.com/pub/complete-price-list.xls](ftp://ftp.lots-o-books.com/pub/complete-price-list.xls)
FTP(File Transfer Protocol)은 서버에 올라가 있는 파일을 가리킨다.

rtsp://www.joes-hardware.com:554/interview/cto_video
RTSP는 스트리밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영상을 가리킨다.

• 이처럼 URL은 인터넷에 있는 어떤 리소스도 가리킬 수 있다.!

대부분 ‘스킴://서버위치/경로’ 구조로 이루어져있다. (프로토콜마다 조금씩 다르지만 저 세 부분은 동일)
⇒ 리소스를 하나의 방식으로 작명하기 때문에 누구나 같은 방식으로 이름을 써서 인터넷의 모든 리소스를 찾을 수 있다.

4. URL이 없던 암흑기🤦🏻‍♀️

처음부터 일관된 명명 방식이 있진 않았다. 웹과 URL이 있기 전, 네트워크 상 산재해있는 데이터에 접근하기 위해선 애플리케이션마다 다른 분류 방식을 사용하여 접근해야 했다.

[ftp://ftp.lots-o-books.com/pub/complete-catalog.xls](ftp://ftp.lots-o-books.com/pub/complete-catalog.xls) 라는 URL로 “complete-catalog.xls’ 파일을 공유하면 되지만

URL이 없을 시기였다면, 파일을 친구와 공유하려 했다면 다음과 같이 설명해야 했다.

(1) “ftp.joes-hardware.com”에 FTP프로토콜로 접속해.

(2) 익명 사용자로 로그인한 다음 비밀번호로 네 이름을 입력해.

(3) pub 디렉토리로 이동하고, 바이너리 형식으로 전환해.

(4) 이제 ‘complete-catalog.xls’란 이름의 파일을 너의 로컬 파일 시스템에 내려받아 보면 돼.

• 많은 사용자들은 URL을 사용하면서 리소스를 가져올 때 사용되는 프로토콜과 접근방식이 무엇인지도 모른다. 왜냐? 브라우저가 알아서 처리해주기 때문에.

웹 브라우저는 URL로 (1)~(4)에 있는 과정을 알아서 처리해주는 기능을 한 패키지에 가지고 있다.

URL은 브라우저와 우리에게 정보를 찾는데 필요한 모든 것을 제공하고, 어디에 위치하고 어떻게 가져오는지 정의한다.

URL 문법 🧵

---

인터넷 상 리소스들은 각각 접근할 수 있는 스킴(HTTP, HTTPS, FTP, SMTP)이 다르며, 그 스킴에 - 따라 URL문법도 조금씩 다르다. 하지만 형태, 문법은 매우 유사하다.

1. URL 전체 컴포넌트(구성요소)

대부분의 URL 스킴의 문법은 9개 부분으로 나뉜다.

<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

• 하지만 위의 9개 컴포넌트를 모두 가지는 URL은 거의 없다.

가장 중요한건 스킴, 호스트, 경로!

(출처 : https://hanseul-lee.github.io/2020/12/24/20-12-24-URL/)

컴포넌트	설명	기본 값
스킴(Scheme)	어떤 프로토콜을 사용하여 서버에 접근해야 하는지 가리킴
사용자 이름	몇몇 스킴은 리소스에 접근하려면 사용자 이름을 필요로 함.	anonymous(익명)
비밀번호	사용자 비밀번호. 사용자 이름에 콜론(:)으로 이어서 기술	이메일주소
호스트(host→ Domain Name or IP)	리소스를 호스팅하는 서버의 호스트 명 혹은 IP주소.
포트(Port)	리소스를 호스팅하는 서버가 열어놓은 포트 번호. 많은 스킴이 기본 포트를 가지고 있음. (HTTP는 80이 기본 포트)	스킴에 따라 다름
경로(Path)	이전 컴포넌트와 slash로 구분(/), 서버 내 리소스가 서버 어디에 있는지를 가리킴. 문법은 서버와 스킴에 따라 다르다. (자세한 건 뒷 부분에서)
파라미터(Parameters)	특정 스킴들에선 입력 파라미터를 기술하는 용도로 사용.
파라미터는 이름/값 쌍을 가지며, 경로 또는 다른 파라미터를 구분하기 위해 세미콜론(;) 사용. 여러 개의 파라미터를 가질 수 있다.
질의(Query Parameters)	애플리케이션(DB, 게시판, 검색엔진 등)에 파라미터를 전달할 때 쓰임. 공통 포맷은 없다. URL끝에 “?”로 구분한다.
프래그먼트(Fragment identifier) (Anchor)	리소스의 조각이나 일부분을 가리키는 이름. 책갈피처럼 기능. 특정 스크롤 위치로 이동할 수 있다.

• 개인적으로 파라미터와 쿼리의 차이를 잘 모르겠어서 찾아봄 파라미터: 특정 id 나 이름을 가지고 조회 쿼리: 키워드 검색, 요청 시 필요한 옵션을 전달 EX) https://www.diggging.com/questions/90 ⇒ 특정 게시물 조회를 위해서 게시물 id를 사용. (id = 90) EX) https://velog.io/search?q=domain ⇒ 검색엔진에서 검색하기위해 키워드 대입. 여기선 q=”keword”형식.

2. 스킴(Scheme): 사용할 프로토콜

URL을 해석하는 애플리케이션은 스킴을 통해서 어떤 프로토콜을 사용해 리소스 요청을 해야하는지 알게 된다.

스킴 컴포넌트는

• 알파벳으로 시작해야하고, url나머지 부분들과 ‘:’로 구분.
• 대소문자를 구분하지 않는다. → http나 HTTP나 똑같음.

3. 호스트(Host)와 포트(Port)

리소스를 찾기 위해선, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 함.

⇒ 호스트와 포트 컴포넌트가 그 정보를 제공.

• 호스트: 접근하려는 리소스를 갖고있는 인터넷상의 호스트 장비를 가리킴.
  • ‘www.diggging.com’과 같은 호스트 명이나 IP 주소로 제공함. 여기서 호스트명은 IP주소의 별명 정도로 생각하면 될 듯.
    DNS는 호스트 명을 IP주소로 변환하여 접근할 수 있게 해줌.
• 포트 : 서버가 열어놓은 네트워크 포트를 가리킴.
  • 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용.

4. 사용자 이름, 비밀번호

데이터 접근을 허용하기 위해 사용자 이름, 비밀번호를 요구하는 서버들이 많다.
그중 대표적 예 : FTP서버.

(1) ftp://ftp.prep.ai.mit.edu/pub/gnu
(2) ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu
(3) ftp://anonymous:my_password@ftp.prep.ai.mit.edu/pub/gnu
(4) http://joe:joespaswd@www.joes-hardware.com/sales_info.txt

(1) : FTP 스킴인데 사용자 이름, 비밀번호 컴포넌트 없음⇒ 기본 사용자 이름, 비번 값을 사용 중일 것임 두 개를 기재하지 않고FTP URL에 접근하면 ‘anonymous’와 브라우저 마다 갖고 있는 기본값 사용.

(2) 사용자 이름이 기본 값, 비밀번호는 기재되어 있지 않다. ‘@’문자로 사용자 이름과 호스트 컴포넌트를 분리한다. ⇒ 사용자 이름@호스트 붙어있어서 이메일 주소처럼 보이기도..

(3) 사용자 이름 기본 값, 비밀번호 ‘my_password’. ‘:’로 둘을 분리한다.

5. 경로(Path)

계층적 파일 시스템 경로와 유사한 구조를 가진다.

‘/’문자를 기준으로 경로조각으로 나뉜다. - 각 경로조각은 자체만의 파라미터를 가질 수 있다.

url경로는 유닉스 파일 시스템의 파일 경로와 유사하다.

6. 파라미터(Parameter)

많은 스킴은 객체에 대한 호스트, 경로 정보만으로는 리소스를 찾지 못한다.

파라미터 컴포넌트는 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받을 때 사용한다.

• 이름/값 쌍의 리스트로 ‘;’로 구분한다.
• 리소스 접근에 필요한 어떤 추가 정보든 전달한다.
• 각 경로조각마다 파라미터 컴포넌트를 가질 수 있다.

http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true

위 url엔 두 개의 경로 조각이 있다.

• hammers: 값이 false인 sale 파라미터를 가진다.
• index.html : 값이 true인 graphics 파라미터를 가진다.

7. 질의 문자열(Query Parameter)

웹 데이터베이스 게이트웨이에 요청할 리소스 형식의 범위를 좁히기 위해 질의를 사용.

ex) 상품 재고 리스트 중 특정 id번호, 색상, size를 특정해서 조회하고 싶을 때.

• 물음표 오른쪽에 있다.
• 게이트웨이를 가리키는 url의 경로 컴포넌트와 함께 전달한다.
• 편의상 많은 게이트웨이가 ‘&’로 나뉜 ‘이름=값’쌍 형식의 쿼리 문자열을 사용한다.

http://www.joes-hardware.com/inventory-check.cgi**?item-1323&color-blue&size=large**

8. 프래그먼트(Fragment)

HTML 같은 리소스 형식은 본래 수준보다 더 작게 나뉠 수 있다.

EX) ~~/tilnote.text ⇒ 텍스트문서 자체를 가리키겠지만 이상적으론 url로 해당 리소스 안의 특정 절을 가리킬 수 있어야 한다.

이처럼 리소스 내의 조각을 가리킬 수 있도록 URL은 프래그먼트 컴포넌트를 제공한다.

• “#”문자 뒤에 온다.

HTTP서버는 객체 일부가 아닌, 전체만 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않는다. 서버로부터 전체 리소스를 다운받고, 프래그먼트를 사용해서 유저가 보고자 하는 리소스의 일부를 보여줄 뿐이다.

🌰 이어서 단축 URL(상대URL, 절대URL) , URL의 문자제한, 스킴, URN에 다루겠습니다!