웹 HTTP 지식 (1편)

Yanagi·2021년 7월 29일
1

HTTP

목록 보기
1/2
  • 업로드 내용은 인프런 김영한님의 '모든 개발자가 웹 http 지식' 강의를 수강한 후, 강의 자료와 검색한 내용을 토대로 재구성 한 것 입니다.

목차


1. 인터넷 네트워크

2. URI 웹 브라우저

3. HTTP

4. HTTP-webbrowser


1. 인터넷 네트워크

1-1. 인터넷 통신

  • 우리가 개발하는 모든 웹은 HTTP 위에서 동작합니다.
  • 평생 HTTP 위에서 일하기 때문에, 개발자들은(특히 백엔드 개발자들은) 사용 목적과 기능을 깊이 있게 이해하는 것이 필요합니다.

1-2. IP(Internet Protocol)

  • 인터넷 프로토콜이 클라이언트와 서버에 IP 주소를 부여합니다.
  • 지정한 IP 주소(IP Address)데이터 전달 패킷(Packet)이라는 통신 단위로 데이터 전달

IP패킷은 출발지, 목적지, 전송 데이터 등으로 이루어집니다.

그림과 같이 노드끼리 서로 패킷을 전달하면서 클라이언트에서 서버까지 도달하게 됩니다.

그런데 여기서 3가지 문제점이 발생합니다.

  • 비연결성
    패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송합니다.
  • 비신뢰성
    중간에 패킷이 사라지거나 패킷이 순서대로 오지 않아도 책임지지 않습니다.
  • 프로그램 구분
    같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때 구별하기 어렵습니다.(예를 들어 음악을 들으면서 게임을 하는 경우)

이를 보완하기 위해 탄생한 것이 TCP/UDP 입니다.

1-3. TCP,UDP

TCP,UDP 를 설명하기 전에 잠시 인터넷 프로토콜 스펙 계층에 대해 설명하겠습니다.
그림과 같이 인터넷 프로토콜 스택은 여러 계층으로 이루어져있습니다.

애플리케이션 계층, 전송 계층, 인터넷 계층, 네트워크 인터페이스 계층이 있으며 각 계층마다 HTTP, FTP ,TCP, UDP, IP 등이 있습니다.

그림의 패킷 전달 과정을 설명하면
1. 프로그램이 Hello, world! 메시지 생성하고
2. SOCKET 라이브러리를 통해 전달을 한 후
3. TCP 정보를 생성하면서 메시지 데이터도 포함합니다.
4. 마찬가지로 IP 패킷을 생성한 후에 TCP 데이터도 포함합니다.

다시 말해 기존의 패킷에 TCP 관련 정보를 포함시킨 것이죠.
택배 상자를 떠올리시면 쉽게 이해가 가능하실 겁니다.(IP 패킷이라는 상자 안에 데이터라는 내용물 포함)

TCP전송 제어 프로토콜(Transmission Control Protocol)의 약자입니다.

TCP 특징은 다음과 같습니다.

  • 연결지향(TCP 3 way handshake)적 입니다.
  • 데이터 전달을 보증합니다.(잘 전달 받았는지 확인합니다.)
  • 전달의 순서를 보장합니다.(순서가 어긋나면 어긋난 곳부터 다시 보내도록 요청합니다.)
  • 신뢰할 수 있는 프로토콜이며 현재는 대부분 TCP 사용합니다.

다음은 연결지향(TCP 3 way handshake)에 대한 추가적인 설명입니다.

연결지향(TCP 3 way handshake)은 실제 연결이 아닌 가상 연결입니다. 개념적인 연결일 뿐 물리적인 연결은 아닙니다.

그림 설명을 하면,

  1. 클라이언트가 우선 접속 요청을 하면
  2. 서버는 요청을 수락함과 동시에 접속 요청을 다시 보냅니다.(요즘은 2번 과정에서 데이터를 전송하는 경우가 많다고 합니다.)
  3. 클라이언트는 서버가 보낸 접속 요청을 수락합니다.

위와 같은 일련의 과정 속에 요청과 수락이 3번 이루어진다고 해서 TCP 3 way handshake라고 이름이 붙여졌습니다.

UDP사용자 데이터그램 프로토콜(User Datagram Protocol)의 약자입니다.

UDP 특징은 다음과 같습니다.

  • 기능이 거의 없기 때문에, 하얀 도화지에 비유되곤 합니다.(IP와 거의 같으며 PORT와 체크섬 정도만 추가됩니다.)
    - TCP의 특징인 연결지향(TCP 3 way handshake), 데이터 전달 보증
    순서 보장 등을 모두 가지고 있지 않습니다.
  • 대신에 TCP에 비해 단순하고 빠릅니다.
  • 애플리케이션에서 추가 작업 필요

1-4. PORT

2-2 에서 보았던 패킷 그림을 자세히 보면 포트가 있음을 확인할 수 있습니다.

PORT의 기능에 대해 설명하겠습니다.

  • PORT란 하나의 IP에서 여러 개의 동작을 할 때 구분하는 것입니다.(2-1의 예시처럼 음악을 들으며 게임을 하는 경우)
  • PORT는 같은 IP 내에서 프로세스를 구분합니다.
  • IP는 아파트, PORT는 아파트의 동,호수 라고 생각하시면 쉽게 이해가 가실 겁니다.
  • PORT는 0번 부터 65535번까지 할당 가능합니다. 0번 부터 1023번 까지는 잘 알려진 포트로 사용하지 않는 것이 좋습니다.

1-5. DNS

DNS는 도메인 네임 시스템(Domain Name System)의 약자입니다.

  • IP는 기억하기 어렵고 변경될 수 있습니다.
  • DNS를 사용하면, 도메인 명을 IP 주소로 변환해줍니다.(전화번호부라고 생각하면 이해가 쉽습니다.)

2. URI 웹 브라우저

2.1 URI

  • URI는 URI(Uniform Resource Identifier)의 약자입니다.
  • URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있습니다.

URI 설명

  • Uniform: 리소스 식별하는 통일된 방식을 뜻합니다.
  • Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)을 의미합니다.
  • Identifier: 다른 항목과 구분하는데 필요한 정보를 나타냅니다.

단어 뜻
URL 설명

  • URL는 Uniform Resource Locator의 약자입니다.
  • Locator: 리소스가 있는 위치를 지정합니다.

URN 설명

  • URN은 Uniform Resource Name의 약자입니다.
  • Name: 리소스에 이름을 부여합니다.
  • 위치는 변할 수 있지만, 이름은 변하지 않는다.
  • URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았습니다.

이 글에서는 URI를 URL과 같은 의미로 다루겠습니다.

다음 URL를 분석 해보도록 하겠습니다.

scheme://[userinfo@]host[:port][/path][?query][#fragment] https://www.google.com:443/search?q=hello&hl=ko

프로토콜(https)

scheme://[userinfo@]host[:port][/path][?query][#fragment] https ://www.google.com:443/search?q=hello&hl=ko

  • 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙입니다.
    예) http, https, ftp 등등
    http는 80 포트, https는 443 포트를 주로 사용합니다.(포트는 생략 가능)
  • https는 http에 보안을 추가한 것입니다. (HTTP Secure)

userinfo

scheme://[userinfo@] host[:port][/path][?query][#fragment] https://www.google.com:443/search?q=hello&hl=ko

  • URL에 사용자정보를 포함해서 인증합니다. 최근에는 거의 사용하지 않습니다.

호스트명(www.google.com)

scheme://[userinfo@] host [:port][/path][?query][#fragment] https:// www.google.com :443/search?q=hello&hl=ko

  • 도메인명 또는 IP 주소를 직접 사용하는 것이 가능합니다.

포트 번호(443)

scheme://[userinfo@]host [:port] [/path][?query][#fragment] https://www.google.com: 443 /search?q=hello&hl=ko

  • 일반적으로 생략합니다. 생략시 http는 80, https는 443입니다.

패스(/search)

scheme://[userinfo@]host[:port] [/path] [?query][#fragment] https://www.google.com:443**/search**?q=hello&hl=ko

  • 리소스 경로(path), 계층적 구조를 보여줍니다.

예)
/home/file1.jpg
/members
/members/100, /items/iphone12

쿼리 파라미터(q=hello&hl=ko)

scheme://[userinfo@]host[:port][/path] [?query] [#fragment] https://www.google.com:443/search? q=hello&hl=ko

  • key=value 형태입니다.
  • ?로 시작, &로 추가 가능합니다. (예를 들면 ?keyA=valueA&keyB=valueB)
  • query parameter, query string 등으로 불립니다. 웹서버에 제공하는 파라미터, 문자 형태 입니다.

fragment

scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html #getting-started-introducing-spring-boot fragment

  • html 내부 북마크 등에 사용합니다.
  • 서버에 전송하는 정보 아닙니다.

2.2 웹 브라우저 요청 흐름

웹 브라우저 요청 흐름을 다음과 같이 그림으로 보겠습니다.


클라이언트와 서버는 전송 데이터와 HTTP 메시지가 담겨있는 패킷을 주고 받게 됩니다.

3. HTTP

3.1 모든 것이 HTTP

  • HTTPHyperText Transfer Protocol의 약자입니다.
  • HTTP 메시지에 HTML, TEXT, IMAGE, 음성, 영상, 파일 ,JSON, XML 등 거의 모든 형태의 데이터를 전송 할 수 있습니다.
  • 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용합니다.
  • TCPHTTP/1.1, HTTP/2 를 기반으로 하며 UDPHTTP/3 을 기반으로 합니다.
  • HTTP/1.1는 가장 많이 사용을 하며 가장 중요한 버전입니다.

3.2 클라이언트 서버 구조

간단하게 그림으로 나타낼 수 있습니다.

3.3 Stateful, Stateless

Stateful, Stateless 차이 정리
상태 유지

  • 중간에 다른 서버로 바뀌면 안됩니다.
  • 중간에 다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.

무상태

  • 중간에 다른 서버로 바뀌어도 됩니다.
  • 갑자기 요청이 증가해도 서버를 대거 투입할 수 있습니다.
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있습니다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능합니다.
  • 서버의 확장성이 높으나 클라이언트가 추가 데이터를 전송해야 하는 단점이 있습니다.

이해하기 쉽게 그림 자료를 함께 첨부하겠습니다.




Stateless의 실무 한계

  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있습니다.
  • 예) 무상태가 필요한 경우: 로그인이 필요 없는 단순한 서비스 소개 화면
  • 예) 상태 유지가 필요한 경우: 로그인
  • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지합니다.
  • 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지를 합니다.
  • 상태 유지는 최소한만 사용합니다.

3.4 비 연결성(connectionless)

이해하기 쉽게 그림을 첨부했습니다.
연결이 지속되면 그만큼 서버 자원을 낭비하게 됩니다.

반면에 요청과 응답이 이루어지고 난 후, 연결을 종료하게 되면 서버 자원의 낭비를 막을 수 있습니다.

비 연결성

  • HTTP는 기본이 연결을 유지하지 않는 모델입니다.
  • 일반적으로 초 단위의 이하의 빠른 속도로 응답합니다.
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작습니다.(웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않음. 서버 자원을 매우 효율적으로 사용할 수 있음.)

한계와 극복

  • TCP/IP 연결을 새로 맺어야 합니다. (해결책:3 way handshake 시간 추가)
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드 됩니다. (해결책: HTTP 지속 연결(Persistent Connections), HTTP/2, HTTP/3에서 더 많은 최적화)

3.5 HTTP 메시지

다음 그림은 HTTP 메시지 구조를 나타냅니다.

4.HTTP-WEBBROWSER

4.1 HTTP API를 만들어보자

API URI 설계해보기

  • 리소스에는 명사가 와야합니다.
    예) 미네랄을 캐라 -> 미네랄이 리소스
    -회원 리스트가 있다고 가정하면, 여기서 회원이라는 개념 자체가 바로 리소스입니다.

리소스를 어떻게 식별하는게 좋을까요?

  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제합니다.
  • 회원이라는 리소스만 식별하면 됩니다. -> 회원 리소스를 URI에 매핑합니다.

예시를 들면 다음과 같습니다.

회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}

참고 사항: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장합니다.(member -> members)

그러면 여기서 행위(조회, 등록, 수정, 삭제)는 어떻게 구별해야 할까요?
여기서 HTTP 메서드 개념이 등장합니다.

4.2 HTTP 메서드 / GET, POST

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용

GET

  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달합니다.
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않습니다.


POST

  • 메시지 바디를 통해 서버로 요청합니다.
  • 데이터 전달 서버는 요청 데이터를 처리합니다.
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행합니다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용합니다.
  • 다른 메서드로 처리하기 애매한 경우에 POST를 사용하면 됩니다.(거의 웬만하면 POST 입니다.)



4.3 HTTP 메서드 / PUT, PATCH, DELETE

PUT

  • 리소스가 있으면 대체하지만 리소스가 없으면 생성합니다.(덮어버림)
  • 클라이언트가 리소스를 식별합니다. 클라이언트가 리소스 위치를 알고 URI 지정합니다. (POST와 차이점)

PATCH

  • 리소스를 부분 수정합니다.

DELETE

  • 리소스를 삭제합니다.

4.4 HTTP 메서드의 속성

  • HTTP 메서드는 크게 세 가지의 속성을 가지고 있습니다.
    • 안전(Safe Methods)
    • 멱등(Idempotent Methods)
    • 캐시가능(Cacheable Methods)

안전(Safe)

  • 호출해도 리소스를 변경하지 않습니다.
  • 그래도 계속 호출해서 로그 같은게 쌓여서 장애가 발생한다면, 안전은 해당 리소스만 고려합니다.

멱등(Idempotent)

  • f(f(x)) = f(x)
  • 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같습니다.

    GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
    PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다. POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

멱등의 활용

  • 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가의 판단 근거가 됩니다.

Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
사용자1: GET -> username:A, age:20
사용자2: PUT -> username:A, age:30
사용자1: GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회
A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

캐시가능 (Cacheable)

  • GET, HEAD, POST, PATCH는 응답 결과 리소스를 캐시해서 사용할 수 있으나, 실제로는 GET, HEAD 정도만 캐시로 사용합니다.
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않습니다.
profile
<'쟤'보단 내가 낫지> 에서 '쟤'를 담당하고 있습니다.

0개의 댓글