HTTP

HTTP 완벽 가이드 스터디 (2)

kchabin 2024. 10. 2. 16:22

스터디 일자 : 8월 9일

https://drive.google.com/file/d/1cqUvkO01SroIjVJt5IPUg_hfmg78Mwi-/view?usp=drive_link

 

2장.drawio

 

drive.google.com

 

스킴://서버위치/경로

 

대부분의 url 구조

URL 문법

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

사용자 이름과 비밀번호

1. 표준 스킴, 호스트, 경로만 존재


2. 사용자 이름


3. 사용자 이름:패스워드


<http://joe:joespasswd@www.joes-hardware.com/sales_info.txt>
  • FTP는 사용자 이름과 비밀번호를 요구하고, 없으면 기본값을 넣는다.
    • anonymous, 비밀번호는 브라우저마다 갖고 있는 기본값
  • @ 는 URL로부터 사용자 이름과 비밀번호 컴포넌트를 분리한다.

경로

리소스가 존재하는 서버의 위치.

  • 계층적 파일 시스템과 유사한 구조를 가짐

파라미터

  • 호스트명, 경로만으로는 리소스 위치를 정확히 파악 어려움
  • 프로토콜 파라미터 가 필요함
  • ftp는 바이너리와 텍스트 두 가지 포맷을 지원하는데, user는 바이너리 이미지가 텍스트 형식으로 깨져서 전송되길 원하지 않는다.

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

ftp.prep.ai.mit.edu/pub/gnu;type=d
  • url에서 경로 컴포넌트를 조각으로 나눌 수 있고, 각 조각은 자체 파라미터를 가진다.
 <http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true>
  • hammers와 index.html 두 개의 경로 조각이 있다.
  • hammers → false 값을 갖는 파라미터 sale
  • index.html → true 값을 갖는 파라미터 graphics

질의 문자열

DB같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있다.

 <http://www.joes-hardware.com/inventory-check.cgi?item=12731>
  • url의 질의 컴포넌트는 게이트웨이를 가리키는 URL의 경로 컴포넌트와 함께 전달
  • & 로 각 질의를 구분한다.

프래그먼트

  • 절(paragraph)이 포함된 용량이 큰 한 개의 텍스트 문서의 경우, 그 리소스에 대한 URL은 텍스트 문서 전체를 가리키겠지만, 이상적으로는 리소스 안에 있는 특정 절을 가리킬 수 있어야 한다.
  • 프래그먼트 컴포넌트는 리소스 내의 조각을 가리킨다. → 이미지, 일부분 등
<http://www.joes-hardware.com>**/**tools.html**#drils**
  • HTTP 서버는 일부가 아닌 객체 ‘전체’를 다루기 때문에, 클라이언트는 서버에 프래그먼트를 전달하지 않는다. → 서버는 전체 html 페이지 반환
  • 브라우저가 리소스를 내려받으면 프래그먼트를 사용해서 보고자하는 리소스의 일부를 보여준다.

단축 URL

상대 URL

  • 절대 url은 모든 정보를 담고 있음
  • 상대 url은 모든 정보를 담고 있진 않으며, 기저(base)라고 하는 다른 url을 사용해서 리소스에 접근한다.
  • url을 처리하는 브라우저같은 애플리케이션은 절대 ↔ 상대 상호 변환 가능해야 함.
  • 리소스 집합(html페이지)을 쉽게 변경 가능함.
    • 위치를 변경하더라도, 새로운 기저 URL에 의해서 해석될 것.
    • 다른 서버의 콘텐츠 미러링과 유사함

💡 URL 변환 과정

기저 URL 찾기

  • 리소스에서 명시적으로 제공 : <BASE> 태그를 기술함.
  • 리소스를 포함하고 있는 기저 URL
  • 기저 URL이 없는 경우 : 절대 URL만으로 이루어짐 / 불완전하거나 깨진 url

상대 참조 해석하기

  • 상대 URL과 기저 URL을 각각의 컴포넌트 조각으로 나눔. → URL 파싱

 

URL 확장

url을 입력하고 있는 중에 자동으로 url 확장

  1. 호스트명 확장
  • 단순한 휴리스틱만 사용
  • ‘yahoo’를 입력하면, 자동으로 www, .com을 붙여서 ‘www.yahoo.com’ 을 만든다.
    • ‘yahoo’란 단어를 포함한 사이트를 찾지 못하면, 확장 포기 전 몇 가지의 url을 추가로 제시한다.
  • 프록시와 같은 다른 http 애플리케이션에 문제를 발생시킬 수도 있음.
  1. 히스토리 확장
  • 과거에 사용자가 방문했던 url의 기록을 저장

안전하지 않은 문자

안전한 전송 : 정보가 유실될 위험 없이 URL을 전송할 수 있다

  • SMTP는 문자를 제거할 수도 있는 전송 방식을 사용함
  • URL은 이를 피하고자 상대적으로 작고 일반적으로 안전한 알파벳만 포함 허락
  • 이스케이프 기능

URL 문자 집합

  • 보통 영어 중심 → US-ASCII
    • 다른 문자 잘 지원 안함
  • 특정 이진데이터를 포함해야 하는 경우
    • URL에 이스케이프 문자열을 쓸 수 있게 설계함.
      • US-ASCII에서 사용이 금지된 문자
  • 인코딩 : 안전하지 않은 문자를 % 기호로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 ‘이스케이프’ 문자로 바꾼다.

문자 아스키 코드 예

~ 126(0x7E) http://joes-hw.com/~joe
빈 문자 32(0x20) http://www.joes-hw.com/more tools.html
% 37(0x25) http://www.joes-hw.com/100%0x25satisfaction.html
  • 100%satisfaction.html 이란 이름의 html 페이지. url의 % 기호는 인코딩용 이스케이프 토큰이고, 퍼센트 표현은 0x25 16진수로 변환한다.

URN

URL은 인터넷 프로토콜 간에 공유할 수 있는 일관된 작명 규칙을 제공하지만, 주소이지 실제 이름은 아니다.

  • 특정 시점에 어떤 것이 위치한 곳을 알려준다.
  • 리소스가 옮겨지면 URL을 더는 사용할 수 없다.

지속 통합 자원 지시자(Persistent uniform resource locators, PURL)

리소스의 실제 URL 목록을 관리하고 추적하는 리소스 위치 중개 서버를 두고, 해당 리소스를 우회적으로 제공

https://purl.archive.org/help

 

PURL help

You will be returned to this page after login.

purl.archive.org

 

느낀점

URL은 막연히 경로로만 생각하고, URI와 매우 헷갈렸었는데, 책을 읽고 직접 그림으로 정리하는 과정에서 좀 더 명확하게 이해할 수 있었다. 

저작자표시 비영리 변경금지