[네트워크] 모든 개발자를 위한 HTTP 웹 기본 지식 정리

다음 강의 정리

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

목차

• 인터넷 네트워크
• URI와 웹 브라우저 요청 흐름
• HTTP 기본
• HTTP 메서드
• HTTP 메서드 활용
• HTTP 상태 코드
• HTTP 헤더

 

인터넷 네트워크

---

IP (Internet Protocol)

• 지정한 IP 주소에 데이터 전달
• 패킷 이라는 통신 단위로 데이터를 전달한다.
• IP 패킷 정보 : 출발지 IP, 목적지 IP, 전송 데이터 등

 

IP 프로토콜의 한계

• 비연결성
  • 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷을 전송한다.
• 비신뢰성
  • 중간에 패킷이 사라지거나, 패킷이 순서대로 오지 않을 수 있다.
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면 어떻게 구분하지?

 

TCP, UDP

• 참고

 

TCP/IP 패킷 정보

• 출발지 PORT, 목적지 PORT
• 전송 제어
• 순서
• 검증 정보 등

 

TCP(Transmission Control Protocol) 특징

• 연결 지향 - TCP 3-way handshake
• 데이터 전달 보증
  • 데이터 전달 후, 서버에서 데이터를 받았다는 응답을 보낸다.
  • 이 응답 여부에 따라 전달이 되었는지를 판단할 수 있다.
• 순서 보장
  • 서버에 패킷 순서가 다르게 도착할 수 있다.
  • 내부적 최적화 로직에 따라 다르게 처리한다.
  • 순서 잘못 온 부분을 알려서, 거기부터 다시 전송하거나 등 여러 방식이 있다고 한다.
• 신뢰할 수 있는 프로토콜
  • 전송제어, 순서, 검증 등의 정보가 포함되어 있어서 가능하다.
• 현재는 대부분 TCP를 사용한다.

 

TCP 3-way handshake

 

• connect, 연결 과정
• SYN : 접속 요청
• ACK : 요청 수락
• 최근엔 마지막 ACK와 함께 데이터를 전송하기도 한다.

 

 

 

 

UDP(User Datagram Protocol) 특징

• 연결 지향적이지 않다.
• 데이터 전달 보증이 안 된다.
• 순서 보장이 안 된다.
• 단순하고 빠르다.
• 즉, IP와 거의 같다.
• PORT, 체크섬이 추가된다는 것이 다르다.
  • PORT : 한 IP에서 여러 애플리케이션을 구분할 때 사용한다.

 

+++ TCP가 90프로 이상 점유했는데, 최근 HTTP3에서는 3way handshake 같은 것도 더 줄이자는 생각으로 최적화 하면서, UDP를 쓰고 있다. -> 도화지 같은 거라 자신이 원하는거 추가하면 되기 때문

 

PORT

• 배가 도착하는 항구라는 의미다.
• IP는 주소, PORT는 상세주소로 비유할 수 있다.

 

• 이런 상황에서, 패킷이 어디서 온 건지 구분하기 위해 port를 사용한다.
• 0 ~ 65535 : 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 즉 사용하지 않는게 좋다.
• FTP : 20, 21
• TELNET : 23
• HTTP : 80
• HTTPS : 443

 

TCP/IP 패킷 정보

• 출발지 IP, PORT
• 목적지 IP, PORT

 

DNS (Domain Name System)

• IP는 기억하기 어렵고, 변경될 수 있는데 이러한 문제를 해결할 수 있는 시스템이다.
• 일종의 전화번호부다.
• 도메인 명을 IP 주소로 변환해준다.

 

 

URI와 웹 브라우저 요청 흐름

---

URI(Uniform Resource Identifier)

• 리소스를 식별하는 통합된 방법
• URL -> L은 Locator
• URN -> N은 Name
• 둘 중 하나 또는 둘 다 추가로 분류될 수 있다. 

 

URI 단어 뜻

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음)
• Identifier : 다른 항목과 구분하는데 필요한 정보
• URL : 리소스가 있는 위치를 지정
• URN : 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
•  URN 이름만으로 실제 시로스를 찾을 수 있는 방법이 보편화 되지 않았다.

 

URL 전체 문법

scheme://[userinfo@]host[:port][/path][?query][#fragment]

ex)

https://www.google.com:443/search?q=hello&hl=ko

프로토콜 // 호스트명 : 포트번호 / 패스 ? 쿼리 파라미터

• scheme
  • 주로 프로토콜 사용
  • 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
  • http, https, ftp 등
  • http : 80 포트
  • https : 443 포트를 주로 사용
  • 포트는 생략 가능하다.
• userinfo : 거의 사용하지 않는다.
• host
  • 호스트명
  • 도메인명 또는 IP 주소를 직접 사용 가능
• port
  
  • 접속 포트
  • http 80, https 443은 일반적으로 생략한다.
• path
  • 리소스 경로, 계층적 구조
• query
  • key=value 형태
  • ?로 시작, $로 추가 가능하다.
  • query parameter, query string 등으로 불린다.
  • 웹 서버에 제공하는 파라미터, 문자 형태
• fragment
  • html 내부 북마크 등에 사용한다.
  • 서버에 전송하는 정보는 아니다.

 

웹 브라우저 요청 흐름

 

 

HTTP 기본

---

모든 것이 HTTP

• HTTP 메시지에 모든 것을 전송한다.
• 음성, 영상, 파일, text, JSON 등 거의 모든 형태의 데이터 전송 가능하다.
• 서버간에 데이터를 주고 받을 때도 대부분은 HTTP를 사용한다.

 

기반 프로토콜

• TCP : HTTP/1.1, HTTP/2
• UDP : HTTP/3
• 현재 HTTP/1.1 주로 사용
• HTTP/2 는 성능개선
• HTTP/3는 TCP 대신 UDP 사용, 성능 개선

 

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜 (stateless), 비연결성
• HTTP 메시지
• 단순함, 확장 가능

 

클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답
• 클라이언트와 서버로 개념 분리
  • 서버는 비즈니스 로직 및 데이터에 집중
  • 클라이언트는 ui 및 사용성에 집중
  • 이렇게 하면 각각 독립적으로 진화할 수 있다.

 

무상태 프로토콜 (Stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 장점 : 서버 확장성 높음 (스케일 아웃)
• 단점 : 클라이언트가 추가 데이터 전송

 

stateful / stateless 차이

ex)

• stateful - 상태 유지
  • 서버가 클라이언트의 이전 상태를 보존한다.
  • 중간에 다른 점원으로 바뀔 때, 상태 정보를 다른 점원에게 미리 알려줘야 한다.
  • 즉, 항상 같은 서버가 유지되어야 한다.
  • 중간에 서버가 장애나면? -> 클라이언트는 같은 요청을 다시 처리해야 한다.
• stateless - 무상태
  • 중간에 다른 점원으로 바뀌어도 된다.
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능 (스케일 아웃 - 수평 확장 에 유리하다.)
  •  클라이언트가 요청할 때 필요한 데이터를 다 담아서 보내기 때문에, 서버는 상태를 보관하지 않고, 응답만 한다.
    -> 서버에 장애가 발생해도, 중계서버가 다른 서버에 요청을 보내 해결할 수 있다.
  • 한계
    1. 모든 것을 무상태로 설계할 수 있는 경우도 있고, 아닌 경우도 있다.
       ex)
       - 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면
       - 상태 유지 : 로그인
       => 따라서 상태 유지는 최소한만 사용해야한다.
    2. 전송해야 되는 데이터의 양이 많다.

 

비 연결성 (connectionless)

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답한다.
• 서버 자원을 매우 효율적으로 사용할 수 있다.
• 1시간 동안 수천명이 서비스를 사용해도, 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
• 즉, 자원의 가용성을 훨씬 높여, 자원을 더 효율적으로 사용할 수 있다.

 

한계와 극복

• TCP/IP 연결을 새로 맺어야 한다. -> 3-way handshake 시간이 추가된다.
• 웹 브라우저로 사이트를 요청하면, HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드 된다. -> 많은 자원을 계속 연결하고 받고 하는 과정은 비효율적이다.
• 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
• HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 메시지

• HTTP 메시지 구조

start-line	request line || status-line reqyest line :  메서드 + target (요청대상)  + HTTP 버전 status-line : HTTP 버전 + status-code + reason-phrase (상태코드 나타내는 짧은 글) 메서드 : GET, POST, PUT, DELETE 등
header	header-field : field-name + ":" + field-value HTTP 전송에 필요한 모든 부가정보 ex) 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트 정보 등 필요의 임의의 헤더 추가 가능
empty line (CRLF)	엔터라고 이해해라
message body	실제 전송할 데이터 HTML 문서, 이미지, 영상, JSON 등 byte로 표현 가능한 모든 데이터 전송 가능

 

HTTP 메서드

---

HTTP API 만들기

• 요구사항 : 회원정보를 관리하는 API를 만들어라

1. API URI 설계

• 회원목록 조회, 회원 조회, 회원등록 , 회원 수정, 회원 삭제
  
  
• 가장 중요한 것은 리소스 식별이다.
• 리소스란? => 회원이라는 개념 자체가 리소스다. 회원을 등록하고 수정하는 것이 아닌!
• 리소스 식별 방법
  • 회원을 등록, 수정, 조회하는 것을 모두 배제해라.
  • 회원이라는 리소스만 식별하면된다.
  • 회원 리소스를 URI에 매핑

/read-memeber-list	->	/memebers/{id}
/create-member	->	/members/{id}

• 이제 조회, 등록, 수정, 삭제를 어떻게 구분할까?

리소스와 행위를 분리

• URI는 리소스만 식별한다.
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리한다.
• 리소스  : 회원
• 행위 : 조회, 등록, 삭제, 변경

 

HTTP 메서드 - GET, POST, PUT, PATCH, DELETE

GET	리소스 조회 - 메시지 바디를 사용해 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장하지 않는다.
POST	요청 데이터 처리, 주로 등록에 사용 - 메시지 바디를 통해 서버로 요청 데이터 전달 - 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
PUT	리소스를 대체(덮어쓰기), 해당리소스가 없으면 생성 - 클라이언트가 리소스를 식별한다. => 이게 post와 put의 큰 차이점이다. post는 구체적으로 지정하지 않는다.
PATCH	리소스 부분 변경 - PATCH가 지원이 안 되는 서버의 경우 POST를 사용한다.
DELETE	리소스 삭제
HEAD	GET과 동일하지만 메시지 부분을 제외하고, 상태줄과 헤더만 반화
OPTIONS	대상 리소스에 대한 통신 가능 옵션을 설명한다. 주로 (CORS에서 사용)

 

HTTP 메서드의 속성

안전 (Safe Methods)

• 호출해도 리소스를 변경하지 않는다.
• 계쏙 호출해서 로그가 쌓여 장애가 발생하는 것과 같은건 고려하지 않고, 오로지 리소스만 고려한다.
• 리소스를 수정하지 않는 것은 안전한 것이고(조회 등), 무언가 변경이 일어나는 것(수정 등)은 안전하지 않은 것이다.

 

멱등 (Idempotent Methods)

• f(f(x)) = f(x)
• 몇 번을 호출한든 모든 결과가 똑같다.
• 멱등 메서드 : GET, PUT, DELETE
• POST는 멱등이 아니다 => 두번 호출하면 결제의 경우 같은 결재가 중복 발생할 수 있다.
• 활용
  • 자동 복구 메커니즘
  • 서버가 timeout 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시해도 되는가? 판단근거
• 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.

 

캐시가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD  정도만 사용한다.
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.

 

HTTP 메서드 활용

---

클라이언트에서 서버로 데이터 전송

• 데이터 전달 방식은 크게 2가지
  1. 쿼리 파라미터를 통한 데이터 전송 - GET / 주로 정렬 필터(검색어)
  2. 메시지 바디를 통한 데이터 전송 - POST, PUT, PATCH / 회원가입, 상품주문, 리소스 등록, 리소스 변경
• 4가지 상황
  1. 정적 데이터 조회 : 이미지, 정적 텍스트
  2. 동적 데이터 조회 : 검색
  3. HTML Form을 통한 데이터 전송 : multipart/form-data
  4. HTTP API를 통한 데이터 전송

 

HTTP API 설계 예시

 

 

 

HTTP 상태 코드

---

상태코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

1xx	Informational	요청이 수신되어 처리중
2xx	Successful	요청 정상 처리
3xx	Redirection	요청을 완료하려면 추가 행동 필요
4xx	Client Error	클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx	Server Error	서버 오류, 서버가 정상 요청을 처리하지 못함

 

• 2XX
  • 200 : 요청성공
  • 201 : 요청 성공해서 새로운 리소스 생성됨
  • 202 : 요청이 접수되었으나, 처리가 완료되지 않았음 ex) 배치프로세스
  • 204 : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 ex) 문서편집 save 버튼
• 3XX
  • 리다이렉션 : 웹브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
  • 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동 (301, 308)
  • 일시 리다이렉션 : 리소스의 URI가 일시적인 변경 (302, 307, 303)
    - POST / Redirect / Get 요청시 사용
    - ex) POST로 쇼핑몰 주문후 새로고침으로 인한 중복 주문 방지
  • 특수 리다이렉션: 결과 대신 캐시를 사용
  • 304 : 캐시를 목적으로 삳용, 클라이언트에게 리소스가 수정되지 않았음을 알려준다.

• 4XX
  •  

 

HTTP 헤더

---