Create 1-2 URL-(1) : url and resourc.MD

HTTP Perfect Guide/1-2 URL-(1) : url and resourc.MD

@@ -0,0 +1,253 @@
+# 들어가기 ) URL을 왜 사용하는가?
+
+### 인터넷 = 거대한 도시라고 가정해보자.
+
+우리는 도시의 수많은 볼거리와 서비스들을 지칭하는 ‘표준 작명 프로토콜’을 사용하기로 한 것이다.
+
+- 박물관, 레스토랑, 주택을 설명하기 위해 ‘길거리 주소’를 사용함
+- 다른 사람에게 연락하기 위해 ‘전화번호’ 사용함
+
+**리소스들은 적절히 분류되기 위해 각자 저만의 표준화된 이름을 가진다.**
+
+- 책들은 책 분야, 내용에 따라 ISBN 번호로 분류됨.
+- 버스는 노선에 따라 노선번호를 가짐.
+- 은행 계좌는 계좌번호를 가짐
+- 사람들은 사회보장번호(주민등록번호)를 가짐.
+
+이렇게 표준화된 이름이 다양한 리소스에 정해져 있고, 
+우리가 그것에 동의하여 사용하고 있기 때문에 
+우리는 소중한 리소스들을 모두 쉽게 공유할 수 있으며, 의사소통을 쉽게 할 수 있다.
+
+EX) 택시기사에게 “관악구 관악로 1 - 64동으로 가주세요”라고 말하면 어느 곳을 말하는지 안다. 최소 내비게이션은 안다..
+
+URL(Uniform Resource Locator)은 인터넷 리소스를 가리키는 표준 이름이다. 
+그것이 어디에 있으며, 어떻게 접근할 수 있는지를 알려준다.
+
+# 인터넷의 리소스를 탐색하는 URL
+
+---
+
+## 1. URL은...
+
+브라우저가 정보를 찾는데 필요한 **리소스의 위치**를 가리킨다. ⇒ (Locator)
+
+덕분에, 사람과 애플리케이션이 인터넷 상의 수십 억 개의 리소스를 찾고 사용하며 공유할 수 있다.
+
+사용자가 브라우저에 URL을 입력하면, 브라우저는 사용자가 원하는 리소스를 얻기 위해 적절한 프로토콜을 사용하여 메시지를 전송한다. (사용하는 프로토콜은 URL에 명시되어있다-가장 앞 부분)
+
+
+
+![대단한 그림판 실력ㅋ](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/4bbc1c43-1d65-45fd-88df-e0714dc824fd/Untitled.png)
+
+대단한 그림판 실력ㅋ
+
+URL은 URI(Unifrom Resource Identifier, 통합 자원 식별자)라고 불리는 더 상위 개념의 부분집합이다.
+
+URI는 URL, URN을 포함하는 개념이다. 참고로 URL은 위치를 통해 자원을 식별하고, URN은 고유한 이름을 통해 자원을 식별한다. 
+
+## 2. URL의 구조
+
+예시 url
+
+```jsx
+http://www.joes-hardware.com/seasonal/index-fall.html                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
+```
+
+이라는 url을 불러오고 싶다고 해보자.
+
+- URL 첫 부분인 `http` 는 URL의 **스킴**이다. 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다. 이 경우, ‘HTTP 프로토콜’을 사용하여 접근한다.
+- URL 두 번째 부분 `www.joes-hardware.com`은 **서버의 위치**를 알려준다. 리소스가 어디에 호스팅이 되어있는지 알려주는 것.
+- URL 세 번째 부분 `/seasonal/index-fall.html` 은 리소스의 경로다. 서버에 존재하는 로컬 리소스들 중 요청받은 리소스가 무엇인지 알려주는 것.
+
+    ![DD0426C0-0CE4-4353-9DE5-2E3A48092EB6.jpeg](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/eb5ae1d4-dcdc-4019-8b4d-93ca43303a15/DD0426C0-0CE4-4353-9DE5-2E3A48092EB6.jpeg)
+
+
+- 스킴 : 어떻게(리소스에 어떻게 접근), 호스트: 어디에(리소스가 어디에) 경로: 무엇을(어떤 리소스를)
+
+⇒ 즉 URL은 브라우저, 컴퓨터, 서버, 서버파일 시스템의 어디에 위치하고 어떻게 연결되는지 보여준다.
+
+## 3. HTTP가 아닌 다른 프로토콜
+
+`mailto:[email protected]` 
+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개 부분으로 나뉜다. 
+
+```jsx
+<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
+```
+
+- 하지만 위의 9개 컴포넌트를 모두 가지는 URL은 거의 없다.
+
+가장 중요한건 **스킴, 호스트, 경로**!
+
+![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/84a6fae8-16d1-421a-9b87-1bccef9ff934/Untitled.png)
+
+(출처 : [https://hanseul-lee.github.io/2020/12/24/20-12-24-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](https://www.diggging.com/questions/90)
+
+    ⇒ 특정 게시물 `조회`를 위해서 `게시물 id`를 사용. (id = 90)
+
+    EX) [https://velog.io/search?q=domain](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://[email protected]/pub/gnu
+(3) ftp://anonymous:[email protected]/pub/gnu
+(4) http://joe:[email protected]/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서버는 객체 일부가 아닌, 전체만 다루기 때문에 클라이언트는 서버에 프래그먼트를 전달하지 않는다. 서버로부터 전체 리소스를 다운받고, 프래그먼트를 사용해서 유저가 보고자 하는 리소스의 일부를 보여줄 뿐이다.
+
+<aside>
+💡 이어서 단축 URL(상대URL, 절대URL) , URL의 문자제한, 스킴, URN에 다룬다.
+
+</aside>
+