[1장 ~ 2장] 1.7 ~ 2.4

책을 읽고 공부한 내용을 기록한 글입니다.

HTTP의 프로토콜은 버전이 여러가지다. 그 중 현재 쓰이고 있는 1.1이 가장 많이 사용되고, 지금 사용하는 대다수의 기능이 포함된 1.0의 최적화 버전이다. HTTP/1.0+ -> HTTP/1.1로 갔다고 봐야한다. 2.0은 2015년에 도입이 시작됐으나 아직 개발중이다.

웹 앱에 대한 이야기를 하기 전에 용어 정리를 하고 가자.

• 프락시(Proxy) - 클라이언트 - 서버 사이의 중개자. 프락시는 클라이언트의 모든 요청을 서버로 전달한다. 중개역할을 하면서 필터링 기능도 수행할 수 있어 보안을 위해 사용되기도 한다.
• 캐시 - 자주 찾는 웹페이지를 클라이언트 쪽에 보관
• 게이트웨이 - 다른 앱과 연결된 특별한 웹 서버
• 터널 - 단순 HTTP 통신만 담당하는 특별한 프락시
• 에이전트 - 웹 클라이언트(자동화된 HTTP 요청 생성)

캐시는 자주 찾는 문서의 사본 저장해두는 특별한 프락시(웹 서버, 캐시 프락시)다. 매번 웹 서버에서 문서를 가져오는 것보다 캐시해 저장해 둔 걸 빼오는 게 자주 찾는 문서라면 효율적이다. 

게이트웨이 또한 중개자인데, 서버들의 중개자다. HTTP가 FTP서버에 대한 요청을 수행하면, HTTP/FTP게이트웨이가 HTTP 요청을 받아 FTP 프로토콜을 이용해 문서를 갖고오고, HTTP 응답으로 넘겨준다.

터널은 그냥 두 커넥션 사이의 데이터를 전달해주는 통로다. 주로 비 HTTP 네트워크와 HTTP 네트워크 사이를 연결해주는 역할을 수행한다. 

 

URL과 리소스

URL은 1장에서 URI - URL - URN 하면서 간단하게 살펴봤다. 인터넷의 리소스(웹에서 식별가능한 모든 것)를 가리키는 표준 이름이다.

앞에 https는 프로토콜이라고도하고, 스킴이라고도 한다. 알파벳으로 시작해야하며 대소문자를 구분하지않는다. 웹 클라이언트가 어떻게 리소스에 접근할지 정의하는 것이고, 이경우 https 프로토콜을 사용한다. 도메인 호스트와 포트로 구성되는데 여기서는 호스트만 써있다. 호스트는 리소스를 가져올 서버의 위치(호스팅 중인 위치)이며, 마지막 부분은 서버 내 리소스의 위치가 적힌 path다. 대부분의 URL은 어떻게 - 어디서 - 무엇을 에 대치되는 스킴://서버위치/경로 구조다. 

URL 문법은 아래와 같다. 

쿼리까지 포함하면 질의 문법인 ?parameter=value 도 있고(공통 포맷은 아니다.)

리소스 일부분을 가리키는 프래그먼트 # 도 있다. 질의문법이나 프래그먼트는 path 다음에 붙는다. 

 

사용자 이름과 비밀번호 url의 컴포넌트가 되기도 한다. FTP 프로토콜은 사용자 이름과 비밀번호를 요구하는데 아래와 같은 구조로 되어있다.

기본 사용자 이름은 anonyomus이고, 기본 비밀번호는 브라우저 기본값을 사용한다. 이름과 비밀번호를 : 로 구분한다.

파라미터와 query string

더 리소스에 구체적으로 접근하기 위해서는 추가적인 정보가 필요하다. 이때 사용되는 것이 파라미터 컴포넌트다.

파라미터는 key-value형태의 리스트로 path뒤의 ; 이후로는 파라미터라고 보면 된다. path는 여러 path를 이어붙여서 사용할 수 있는데, 이때 각 path가 파라미터를 가질 수 있다.

파라미터에서 그치지않고 리소스의 범위를 더 좁히기 위해 쿼리 문자열을 사용할 수 있다.

?parameter=value& 형태로 게이트웨이에 넘기면 게이트웨이가 해당 쿼리 요청값으로 탐색해서 리소스를 찾는다. 

파라미터 컴포넌트와 query string의 차이점을 여기서 알 수 있는데, 파라미터가 path를 더욱 구체화 시키는 용도라면, query string은 게이트웨이 애플리케이션으로 전달하기 위한 탐색 조건이라고 할 수 있다.  또 가장 큰 차이는 질의는 URL 의 일부라는 것이다. 반면 파라미터는 form-data 형태로 URL에 노출되지않고 전송할 수 있다.

 

프래그먼트는 리소스를 더 잘게 쪼개기 위한 방법이다. HTTP 서버는 객체 전체를 다루기 때문에, 응답으로 전체 객체를 갖게 되는데, 일부부만 보여줘야한다면 프래그먼트를 사용할 수 있다.(프래그먼트가 필요하다고 일부객체를 요청할 수 없다.) 공식문서를 읽을 때 각 절이 프래그먼트로 나뉜 것을 볼 수 있을 것이다. 

https://developer.android.com/training/dependency-injection?hl=ko&authuser=1#fundamentals

 

단축 URL

URL은 상대 URL과 절대 URL로 나뉜다. 상대경로, 절대경로와 같은 개념이 맞다. 상대경로는 baseURL을 기반으로 url을 작성한다. 현재 경로를 나타내는 .를 사용하는데, 현재 문서의 위치가 http://xyz.com/tools.html/라면, 

http://xyz.com/tools.html/hammers.html -> ./hammers.html로 바꿀 수 있다. 

브라우저는 상대URL을 절대 URL로 변환해서 알아먹는다. 아래는 순서도다. 

브라우저에서 주소창에 입력할 때, url이 자동완성되는 걸 경험했을 것이다. 이걸 URL확장이라고 하는데 호스트명 확장, 히스토리 확장으로 구분할 수 있고 이전 방문기록을 참고해서 확장해주는게 히스토리 확장, 크롬에서 단어만 검색해도 구글 검색으로 넘어가는게 호스트명 확장으로 볼 수 있다.

URL에도 존재하는 이스케이프

실제로 경험한 적이 있는 이슈다. URL에 api key값을 붙여서 http 요청을 보내야하는데 계속 오류가 나서 봤더니 인코딩 문제로 잘못된 url이 요청되고 있었다. URL이 미리 예약해둔 문자들을 요청 url에 이스케이프 없이 사용하면 다 변환돼서 요청 url이 깨지기 때문에 항상 확인해야된다.

%를 이스케이프 없이 사용한다? 그러면 내 요청 값에 %가 있어야할 자리에 %25가 위치하고 있을 것이다.

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^