Web 개발 :: HTTP와 웹의 동작 방식

HTTP와 웹의 동작 방식_DNS, TCP/IP, Client/Server, request method, status code, header

01. HTTP 웹의 요청흐름

- 웹 브라우저의 흐름
(1) DNS(Domain Name System) 조회
: 웹 브라우저는 고유의 IP를 갖고 있다. (도메인이 이름이라면, IP는 전화번호 같은 개념)
터미널에서 nslookup '주소' 검색시 ip address 확인 가능하다.

nslookup www.naver.com

(2) HTTP 요청 메시지 작성 : request.GET 또는 request.POST 등.., Request Headers(User-Agent, Accept 등..)
(3) Socket 라이브러리를 통해서 전달
(4) TCP/IP 작성(내부에 HTTP 메시지 포함)

- 프로토콜 계층

어플리케이션 → Socket Library → TCP → IP → LAN → 인터넷

- 인터넷 프로토콜(IP, Internet Protocol)
· 지정한 IP주소로 전송
· 출발지 IP와 목적지 IP를 작성
· 노드들을 거쳐서 송신이 된다.
· 한계 : 받을 대상이 없을 수도 있다.
중간에 패킷이 손실되거나 순서대로 오지 않을 수 있다.
같은 IP를 사용하는 어플리케이션이 여러 개라면 문제가 생긴다.

- TCP(IP를 보완)
· 출발지 port와 목적지 port 정보
· 전송제어와 순서
· 검증 정보 등이 실린다.
· 특징 : 연결지향 TCP 3way handshake를 통해 연결이 되었는지 확인한다.
데이터 전달을 보증한다.
순서를 보장한다.
신뢰할 수 있어서 현재 대부분 TCP를 사용한다.

- UDP(User Datagram Protocol)
· 기능이 거의 없으며, IP와 유사하지만 포트와 체크섬이 추가되었다.
· 어플리케이션에서 추가 작업이 필요하며, 원하는 기능들을 추가할 수 있다.

- Port(한글로는 항구)
· 한 컴퓨터에서 게임, 화상통화, 웹브라우저를 다 킬 수 있다.
· 포트는 같은 IP 내에서 프로세스 구분을 해줄 수 있다.
· 0~65535까지 사용 가능하지만 0~1023 포트는 잘 알려진 포트로 사용하지 않는 것을 권장한다.

- DNS
· IP는 변경될 수 있으며, 도메인명을 이용해 주소록 처럼 이용할 수 있다.

- URI(Uniform Resource Identifier : 리소스 식별자을 위한 통일된 방식)
· URI는 locator, name 또는 둘 다 추가로 분류될 수 있다.
· URI라는 개념 아래에 URL과 URN이 존재한다.
· 포트 생략시 http는 80, https는 443
· 리소스 경로는 계층적 구조로 이루어져 있다.

02. HTTP 메시지 구조 및 기본 개념

- HTTP(HyperText Transfer Protocol)
· 기존에는 HTML 전송용으로 나왔으나, 현재는 모든 형태를 전송한다.(이미지, 음성, 영상, 파일, json, xml 등)
· 특징
① 클라이언트 서버 구조
Request Response : 클라이언트는 Request를 보내고 Response를 받는다.
클라이언트에는 UI, 서버에는 데이터와 비즈니스 로직을 관리한다.
② 무상태 프로토콜(stateless)
서버가 클라이언트 상태를 보존하지 않는다. 응답서버를 쉽게 바꿀 수 있고, 세션은 로그인 상태를 최소한으로 사용
(*비연결성 : 연결 유지를 하지 않으면서 최소한의 자원 사용)

- 가장 중요한 것은 *리소스 식별이며 리소스와 행위를 분리하는 것이 Restful API
회원이라는 개념 자체가 리소스, 이것이 URI에 매핑되며, 이 행위는 메서드가 된다.
· 리소스 : 회원
· 행위 : 조회, 등록, 삭제, 변경
*http request methods 종류(*참고 링크)
- 주요 method
· GET : 조회, 데이터를 쿼리스트링으로 전달
· POST : 등록, 메시지 바디를 통해 데이터 전달. 데이터를 처리한다.
프로세스를 처리해야 하는 경우(데이터가 없더라도 상태를 변경할 경우)도 있다.
새로운 리소스가 생성되지 않을 수도 있다.
JSON으로 조회데이터 넘기고 싶지만 GET 메서드를 쓰기 힘든경우에 사용한다.
GET은 캐싱을 할 수 있어서 가능한한 GET을 사용한다.
· PUT : 대체, 혹은 생성. 파일 붙여넣기와 유사. 클라이언트가 URI를 지정해서 보낸다.
· PATCH : 부분 변경
· HEAD : GET과 동일하지만 상태줄과 헤더만 반환

- 데이터 전송 방식
1) HTML form을 통한 데이터 전송 :
html form은 GET, POST만 지원한다.
Content-Type:application/x-www-form-urlencoded
· username-jay&age=30 식으로 바디에 데이터 쿼리파라미터처럼 실린다.
· 전송 데이터는 url encoding처리된다.
Content-Type:multipart/form-data
· 파일을 같이 보낼 때 써야 한다. 바이너리 데이터 보낼 때 사용
· 다른 종류의 어려 파일과 폼의 내용 함께 전송 가능
2) HTML API를 통한 데이터 전송
서버 to 서버, 앱 클라이언트, 웹 클라이언트(ajax)
Content-Type:application/json
form 대신 js를 이용한 통신
POST, PUT, PATCH도 메시지 바디로 데이터 전송 가능

- API 설계 예시(회원 관리 - 컬렉션 기반)
· GET/members : 회원 목록
· POST/members : 회원 등록
· GET/members/{id} : 회원 조회
· PATCH, PUT, POST/members/{id} : 회원 수정
· DELETE/members/{id} : 회원 삭제

- 특징
· 클라이언트는 등록될 리소스의 URI를 모른다.
· 서버가 리소스의 URI를 생성한다.
· /memgers가 컬렉션이 된다.

03. HTTP 상태코드

- HTTP 상태코드(※ 참고 링크)

• Informational responses (100 – 199) : 요청이 수신되어 처리중
• Successful responses (200 – 299) : 요청 정상 처리
• Redirection messages (300 – 399) : 추가 행동 필요(리다이렉트 할 때 주로 발생)
• Client error responses (400 – 499) : 클라이언트 에러(잘못된 문법, 오류 원인이 클라이언트에 있을 경우)
• Server error responses (500 – 599) : 서버 에러(서버 내부 문제, 일시 과부하 등)

04. HTTP 헤더

(※ 참고 링크)
· HTTP 전송에 필요한 모든 부가정보(바디의 내용, 크기, 압축, 인증, 요청 클라이언트, 캐시관리 등)

· 표현

• Content-Type : 형식
• Content-Encoding : 압축방식, 압축해서 보내준 경우
• Content-Language : 언어
• Content-Length : 길이(Byte 단위)

· 컨텐트 협상(Content Negotiation)

• 협상 헤더는 요청시에만 사용된다. (Accept, 클라이언트가 선호하는 미디어 타입 전달)
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연언어

· 전송방식

• 단순 전송 : Content-Length
• 압축 전송 : gzip으로 서버에서 압축할 수 있다.
• 분할 전송 : Transfer-Encoding : chunked
• 범위 전송 : Range 명시

· 일반 정보 : refer(유입경로), user-agent(브라우저), server(요청을 처리하는 서버의 소프트웨어 정보)
· 특별 정보 : host(요청한 호스트 정보, 도메인), Allow(허용 가능한 메서드) 등
· 인증 : Authorization(클라이언트의 인증정보를 서버에 전달), WWW-Authenticate(리소스 접근시 필요한 인증방법)
· 쿠키 : HTTP는 무상태 연결이기 때문에 상태를 매번 보내줘야 한다. 모든 요청과 링크에 사용자 정보를 포함해야 하는 단점이 있어 이를 해결하기 위해 쿠키가 도입되었다.
Cookie : 클라이언트가 서버에서 받은 쿠키 저장. 요청시 서버로 전달
Set-Cookie : Response시 서버에서 클라이언트로 쿠키 전달

• 만료기간/경로/도메인을 설정해줄 수 있다.
• 사용처 : 로그인 세션 관리(쿠키-세션방식), 광고 정보 트래킹
• 쿠키는 항상 서버에 전송되다 보니 트래픽이 추가 유발된다. 최소한의 정보만 쓸 것
• 서버에 전송이 필요없고 웹 브라우저에 저장만 하고 싶으면 local storage를 사용하면 된다.
• 보안에 민감한 주민번호, 신용카드 번호 등은 저장하지 않는다.
• 만료일자를 생략하면 브라우저 종료시 삭제
• 만료일(Expires)이나 시간(max age)을 지정할 수 있다.
• 경로 지정으로 원하는 도메인에만 쿠키를 보낸다.

· 캐시(Cache)

• 캐시가 없다면 매번 같은 요청이 와도 헤더와 바디를 새로 보내준다.
• 캐시가 있다면 cache-control을 통해 리스폰스가 캐시의 유효기간을 설정해주고, 응답결과를 브라우저에 저장해두면 두번째 요청을 캐시에게서 받아온다. 만약 유효기간이 지났다면 다시 서버를 통해 데이터를 조회하고 다운로드한다.

· 검증 헤더와 조건부 요청

• 캐시 유효기간 초과한 경우 둘 중 하나의 상황(서버에서 기존 데이터 변경 or 기존 데이터가 동일함)
• 검증 헤더 Last-modified를 추가해서 데이터에 변경이 있었는지 없었는지 정보를 추가한다.
• 검증 헤더를 보고 캐시의 유효기간만 늘려줄 수 있다.
• if-modified-since를 이용해서 다시 보내줘야 하는지 판단할 수 있다. 304를 이용해서 캐시데이터를 쓴다.

· 캐시와 조건부 요청 헤더

• Cache-control : max-age 캐시 유효기간
• Cache-control : no-cache 서버에 검증하고 사용
• Cache-control : no-store 민감한 정보로 최대한 빨리 삭제