URI
URI(Uniform Resource Identifier) : 하나의 리소스를 가리키는 문자열. 리소스를 식별한다?
- Uniform : 리소스를 식별하는 통일된 방식
- Resource : 자원, URI로 식별할 수 있는 모든 것(제한X)
- Identifier : 다른 항목과 구분하는데 필요한 정보
💡 리소스는 단순히 도큐먼트 파일 뿐만 아니라 이미지와 서비스(예 오늘의 일기 예보, 교통량)등 다른 것과 구분 할 수 있는 것을 말한다.
- URL(Uniform Resource Locator) : 리소스의 위치를 지정 , HTTP 맥락에서 URL은 "웹 주소","링크"라고 불린다.
- URN(Uniform Resource Name) : 리소스에 이름을 부여 -> URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않는다.
URL분석
- 프로토콜(https,http,ftp)
- 호스트명(host(domain)
- 포트번호 (생략 가능) : http 80포트 , https 443포트
- 패스(/) : 리소스 경로(path), 계층적 구조
- 쿼리 파라미터(쿼리 스트링) : ?로 시작. &로 추가가능
웹브라우저 요청흐름
https://www.google.com
1. www.google.com DNS 조회 -> IP : 200.200.200.2
2. HTTP 요청 메시지를 생성
3. 소켓라이브러리를 통해 전달
4. TCP 3-way Handshake를 통해 구글과 연결
5. 데이터에 패킷을 씌우고 (IP,PORT정보)
6. 전송데이터를 포함하여 구글 서버에 전달
7. 구글 서버는 TCP/IP패킷을 버리고 HTTP메시지만 꺼내서 해석하기
8. HTTP응답 메시지(HTTP버전 상태코드, Content-Type, Content-Length)
9. 패킷 씌우고 다시 웹브라우저로 전달
10. 웹브라우저는 html 랜더링
HTTP(HyperText Transfer Protocol)
- HTTP 메시지에 모든 것을 전송
- 처음엔 Html만 가능했지만 요즘엔 거의 모든 형태의 데이터 전송이 가능해짐
- 현재 HTTP/1.1 : 가장 중요한 버전
- TCP : HTTP/1.1, HTTP/2
- UDP : HTTP/3
클라이언트 서버 구조
- Request Response 구조
- 반드시 클라이언트측으로 부터 통신이 시작된다.
- 클라이언트와 서버의 역할 분리한다.(독립적)
무상태 프로토콜
- 서버가 클라이언트의 상태를 보존하지 않는다
- HTTP프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않는다.
=> 왜? 데이터를 빠르고 확실하게 처리하기 위해 간단하게 설계되어있다. - 상태유지는 최소한만(최대한 스테이트리스 상태로 설계해야함)
무상태 프로토콜 한계
- 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
- 상태를 유지해야하는 경우 : 로그인 => 쿠키기술 도입
** 쿠키 : 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다. (HTTP를 이용한 통신에도 상태를 계속 관리할 수 있게 해준다.)
비연결성(connectionless)
- 클라이언트가 요청하고 서버가 응답하면 연결을 끊어버린다.(서버가 유지하는 자원을 최소한으로 유지)
- 서버 자원을 효율적으로 사용 가능하다.
비연결성 한계와 극복
- 웹브라우저로 사이트를 요청하면 HTML뿐만아니라 CSS,JS 등 함께 다운로드한다.
- 리퀘스트를 보낼 때 마다 TCP연결과 종료를 하게되어 통신량이 늘어난다.
지속연결(Persistent Connections)
- 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP연결을 계속 유지한다.
- TCP 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 웹 페이지가 빨리 표시 가능하다.
파이프라인화
- 지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게한다.
- 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을 리스폰스를 기다리지않고 바로 다음 리퀘스트를 보낼 수 있다.
HTTP
HTTP 메시지 구조
start-line : 시작 라인
header : 헤더
empty line : 공백 라인(CRLF) **
message body
HTTP 요청 메시지
- request-line : GET /search?q=hello&hl=ko HTTP/1.1(메소드, 요청대상, HTTP버전)
- header : www.google.com
- empty line
- message body
HTTP 응답 메시지
- status-line : HTTP/1.1 200 OK(버전, 상태코드, 이유문구)
- header
- Content-Tye:text/html;charset=UTF-8
- Content-Length:3423
- empty line
- message body
HTTP 헤더 용도
- HTTP 전송에 필요한 모든 부가정보
- 예) 메시지 바디의 내용. 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저)정보, 캐시 관리 정보 등
- 표준 헤더가 많음
HTTP 메시지 바디 용도
- 실제 전송할 데이터
- HTML 문서, 이미지, JSON 등 byte로 표현할 수 있는 모든 데이터 전송가능
