티스토리 뷰
1.HTTP
1.1 http란?
http:// = hyper text transfer protocol
텍스트파일, jpeg이미지, wav음성, mpeg동영상, html페이지, 자바애플릿(?) 등이 전세계의 웹서버로부터 http프로토콜을 통하여 클라이언트의 웹브라우저로 향한다.
http는 신뢰성 있는 데이터 전송 프로토콜(RDT:Reliable data transfer protocol)을 사용하기 때문에 전송 도중 데이터 무손상을 보장한다. 그래서 개발자는 인터넷의 결함에 대해 걱정하지 않아도 되고, 사용자도 데이터 손상 여부를 전혀 고려하지 않아도 된다.
1.2 웹 클라이언트와 서버
- http = 클라이언트가 요청(request) + 서버가 응답(response)
1.3 리소스
- 웹 리소스는 웹 콘텐츠의 원천이다. 리소스는 반드시 정적 파일(텍스트, 이미지, 동영상 등..)일 필요는 없다. 요청에 따라 컨텐츠를 생산하는 프로그램이 될 수도 있다. 웹캠 게이트웨이 주식거래 게이트웨이 같은게 될 수도 있다. 엑셀 파일, 웹 게이트웨이, 검색엔진 등.. 엔드포인트의 모든 요소들은 리소스다.
1.3.1미디어 타입
인터넷에는 수많은 데이터 타입들이 있기 때문에 이를 명시하기 위해 MIME type(multipurpose internet mail extension; 다목적 인터넷 메일 확장자) 이라는 데이터 포맷 라벨을 붙인다.
MIME타입은 전송할 파일을 텍스트로 인코딩을 하는 방식으로 동작한다(binary -> text). 서버에서 보낼때 텍스트로 인코딩하고 header의 Content-type에 MIME타입을 명시하여 클라이언트에게 보내서 클라이언트가 명시된 MIME타입을 보고 text파일을 다시 디코딩(text -> binary)하여 사용하는 것이다.
웹브라우저는 서버가 보낸 MIME 타입을 체크하여 처리 가능한 데이터인지 확인한다. 초기의 웹브라우저는 특이한 확장자는 처리를 못해서, 따로 열어주는 프로그램이 필요했다. response 헤더의 Content-type: text/html; charset=UTF-8 여기서 application이 주 타입, json이 sub 타입이다.
+Headers의 Content-type과 MIME 타입의 차이점은 무엇일까? content-type은 MIME 타입 외에 문자 인코딩(; charset=UTF8), boundary(멀티파트mim타입에는 필수값이다) 이렇게 세가지를 명시해준다. Content-type이 MIME 타입을 포함하는 개념이다.
+Headers에 Content-encoding이 있는 경우도 있는데, 이 경우 인코딩을 한 텍스트 파일을 압축한 경우이다. Content-encoding은 압축한 텍스트 파일이 어떤 방식을 압축이 되었는지 알려준다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
MIME 타입의 전체 목록 - HTTP | MDN
다음은 일반적인 확장자로 정렬된, 문서 타입과 관련된 MIME 타입의 포괄적인 목록입니다.
developer.mozilla.org
여기 mdn에서 MIME타입의 전체 목록을 확인해볼 수 있다.
그런데, 잘 생각해보면, 하나의 리스폰스에는 기본적으로 하나의 미디어만 받아올 수 있다(기본적으로는 one part인 것이다). 하지만, 여러 데이터를 하나의 리스폰스에 받는 경우를 겪어본적이 있을 것이다. 이는 multipart mime type을 이용한 것이다.
1.3.2 URI(Uniform Resource Identifier) 통합 자원 식별자
- 웹서버 리소스는 각자 이름을 가지고 있다. https://bomsbro.tistory.com/mamage/newpost/24?type=post 와 같이 푱표시되고, www상에서 내가 원하는 그 자원의 식별자이다.
URI는 URL과 URN 이렇게 두개의 종류로 나뉜다.
1) URL(Uniform Resource Locator)는 리소스 식별자의 가장 흔한형태이다. https://bomsbro.tistory.com/mamage/newpost/24?type=post 이게 URL 형태의 URI이다.
프로토콜(https://) 인터넷주소(bomsbro.tistory.com) 경로(/mamage/newpost/24) 쿼리스트링(?type-post)이렇게 보통 4파트로 이루어 진다.
2) URN(Uniform Resource name)
URN은 내가 원하는 그 자원에 대해 유일 무이한 이름을 부여하는 방식이다. 이 방식을 사용하면 리소스의 위치가 바뀌더라도 문제없이 동작한다고 한다. 리소스 위치를 분석하기 위한 컴퓨팅자원이 필요하기 때문에 사용되지 않는다고 한다.
- 사람들이 기술적 대화에서 많이 헷갈려하는 URI와 URL에 대한 개인적 견해: https://bomsbro.tistory.com/mamage/newpost/24?type=post를 URI라고 해야할까 URL이라고 해야할까? 기술적 대화에서, CS적인 대화를 할 때는 어떠한 리소스의 웹상에서의 식별자를 의미하는 경우, URN이 사용되는 경우까지 고려해야하므로, URI라고 칭하면된다. 그리고, 구현 관점의 대화에서는 사실상 URL밖에 쓰지 않으므로 리소스의 웹상에서의 식별자를 의미할때 URL이라고 말하면 된다.
1.4HTTP트랜잭션
- http트랜잭션은 1.요청 2.응답 이렇게 두개의 서비스로 이루어져있다. 요청은 http매서드+uri로 이루어 져있으며, 응답은 트랜잭션 결과 상태코드+응답으로 이루어져 있다.
- 모든 http request는 하나의 매서드를 갖는다. GET POST PUT DELETE HEAD OPTION 등..
HEAD: respose에 body를 제외하고 header만 보내라.
OPTIONS: response에 서버에서 지원하는 request methods를 보내라.
나머지는 생략..
- 트랜잭션 상태결과는 상태코드+상태 구절로 이루어져 있다. 상태코드만 응답하면 안되고, 200 OK처럼 상태 구절도 함께 포함되는 것이다. 상태코드는 response메시지의 General에서 확인할 수 있다.
- 웹브라우저는 하나의 페이지를 구성하기 위해 여러 요청을 한번에 보낼 수 있다. 해당 uri의 html을 처음에 가져온 뒤, 그 html안에 들어가는 contents등을 처음 html을 요청한 uri와는 다른 uri에 요청하여 얻어와 html에 실제로 채워넣고 나며지 화면을 그리는 것이다. 웹페이지는 여러 uri의 모음이라고 할 수도 있겠다.
1.5메시지
- http메시지는 단순한 줄 단위의 문자열이다.
- 요청 메시지는 시작줄(General)+요청헤더(request header)로 이루어져 있으며 응답 메시지는 General+Response Header+ 본문(Body)로 이루어져 있다.
1.6 TCP(Transmission Control Protocol)
- http프로토콜의 실제 전송과정이다. http는 tcp의 상위 계층에서 돌아간다.
- http프로토콜은 tcp/ip모델의 application계층이고 tcp/ip모델은 osi 7계층 모델을 모두 포함하는 osi 7계층과는 다른 모델이다.
- tcp는 tcp/ip모델에서 transport계층에 위치한다.
- tcp는 오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않는 데이터 스트림을 보장한다.
- TCP/IP의 연결과정(3 way handshaking)과 종료과정 (4 way handshaking)은 여기 자료를 보면 된다.
https://velog.io/@sangmin7648/TCP%EC%9D%98-%EC%97%B0%EA%B2%B0%EA%B3%BC-%ED%95%B4%EC%A0%9C
TCP의 연결과 해제
TCP의 다양한 연결과 해재
velog.io
-https://bomsbro.tistory.com/mamage/newpost/24?type=post 은 https가 443을 가리키고 있고, bomsbro.tistory.com이 브라우저에 의해 dns를 거쳐 ip주소로 변환된다. 그렇게 되면 224.0.1.4:443이런 식으로 웹상의 서버위치를 찾을 수 있고, 그 위치에 가서 tcp 커넥션이 일어나는 것이다.
- 왜 많은 네트워크 강의들에서 텔넷을 실습도구로 사용하는가? tcp수준의 요청을 텍스트 입력을 통해 실습해 볼 수있기 때문이다. 텔넷은 텍스트 입력 기반의 tcp 통신 툴이다. 요즘은 netcat이라는 툴이 udp tcp기반의 통신 툴로서더 대세인 듯하다.
1.7 HTTP 프로토콜의 버전
- 0.9(1991년) -> 1.0 -> 1.0+(1990년대 중반) -> 1.1(1990년대 후반부터 현재까지 그 사이에 약간씩 변경되기는 했다.) -> 2.0(설계가 진행중이다. 구글의 SPDY기반이다.) 순으로 발전되었다. 높은 버전의 http 프로토콜은 서버에서 지원을 해줘야 사용가능하다.
1.8 클라이언트와 서버 사이에 있거나 함께 동작할 수 있는 다른 웹의 구성요소
1)프록시
2)캐시
3)게이트웨이
4)터널
5)에이전트: 자동화된 클라이언트 ex) 챗봇, 크롤러, 스파이더, 웹로봇 등..
+ http pocket reference(Oracle), w3 protocols(W3), http/1.1 공식명세(ietf.org/rfc/rfc2626.txt), http/1.0 공식명세(ietf.org/rfc/rfc1945.txt) 등을 읽어보면 좋을 거라고 한다.
+w3.org/history.html에서 웹의 역사 http의 탄생 등을 볼 수 있다고 한다.