📘 http?

HTTP?

HTTP(HyperText Transfer Protocol)는 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신규약이다. 쉽게말해 웹에서 데이터를 주고 받는 규칙이다.

HTML, TEXT, IMAGE, 음성, 영상 파일, JSON, XML등 거의 모든 형태의 데이터가 전송가능하다.

그렇다면 왜 이름이 “HyperText”일까?

처음 HTTP가 만들어졌을 때는 웹 페이지(HTML 문서)를 주고받는 것이 목적이었다.
그래서 “하이퍼텍스트 전송 규약”이라는 이름이 붙었다.

하지만 지금의 HTTP는 단순히 HTML만 보내는 것이 아니다.
웹 페이지도 보내고, 이미지도 보내고, 로그인 결과(JSON)도 보내는 등 현대의 HTTP는 웹 위에서 오가는 거의 모든 데이터의 운반 규칙이라고 보면 된다.

그럼 어김없이 나오는 질문..왜 필요할까??

우리가 브라우저에 https://google.com 입력한다 해보자
그 순간 브라우저는 서버에게 “google.com 페이지 좀 주세요”라고 요청한다. 그리고 서버는 HTML 문서를 보내준다.
이때 사용하는 약속이 HTTP다.

---

HTTP 동작 방식

기본적으로 요청(Request)과 응답(Response)의 구조이다.
예를들어 클라이언트가 요청을 하고 서버에서 응답이 올 때까지 기다린다. 그리고 서버는 요청에 대한 결과를 만들어 응답한다.

• 요청
  • 브라우저가 서버에게 보낸다
  • GET /users/1 HTTP/1.1
    • GET → 조회
    • /users/1 → 이 주소 요청
    • HTTP/1.1 → HTTP 버전
• 응답
  • HTTP/1.1 200 OK
  • Content-Type: application/json
  • { “id”: 1, “name”: “Seungje” }
    • 200 OK → 성공
    • JSON 데이터 전달 (아이디와 이름)

---

HTTP의 버전 (역사)

HTTP/0.9

• GET 메서드만 지원
• HTTP 헤더 x

HTTP/1.0

• 메서드, 헤더, 상태코드 추가
• 상태코드와 content-type이 생겨 html 파일 외에 다른 타입 파일도 전송
• 요청마다 커넥션 수립(매번 새로운 연결) -> 느림
• 커넥션 하나당 요청 하나와 응답 하나만 처리함

HTTP/1.1

• 현재 가장 많이 사용
• 한번에 여러 요청 가능
• 파이프라이닝(Pipelining) 지원 : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식 -> HOL Blocking 문제
  • Head Of Line Blocking : 우선 순위로 들어온 요청의 응답 시간이 길어지면 후 순위에 있는 요청의 응답시간도 길어지는 단점

HTTP/2.0

• HTTP/1.1 성능 개선 및 확장
• 바이너리 프레이밍 계층 사용의 메세지 전송 방식 변화
  • 1.0의 text 형식 전달에서 요청, 응답 메시지는 프레임 단위로 나누어지는 것
• 오류 발생 가능성 저하
• 파싱, 전송속도 증가
• HOL Blocking 문제 해결 -> 멀티플렉싱(Multiplexed Streams)
  • 
  • 하나의 연결에서 여러 요청과 응답을 동시에 주고받는 기술
• Header 중복 문제 해결 (HPACK 압축)

HTTP/3.0

• TCP 대신 UDP를 이용한 QUIC 프로토콜 사용
  • 지금까지는 TCP 방식을 사용했지만(TCP에 대해서는 추후 자세히 설명 예정), 3.0부터는 UDP QUIC(UDP 위에 TCP 기능을 소프트웨어로 구현한 프로토콜) 사용

이렇게 보면 3.0이 제일 좋은거니까 다 3.0만 사용하면 되는거 아니냐?라 생각할 수 있다.
나도 그렇게 생각했는데 아니다..쉽게 설명해주마

HTTP/1.1 = 수동 기어, 오래됐지만 어디서나 가능
HTTP/2 = 자동 변속기, 효율 좋아짐
HTTP/3 = 최신 전기차, 빠르고 효율적

전기차가 나왔다고 지금 우리가 모두 전기차를 타지 않는것 처럼 똑같다 이것도.

---

HTTP 특징

무상태성 (Stateless)

앞선 API 관련 글에서 자세히 설명했으니 간단하게만 설명한다.
서버가 이전 요청을 기억하지 않는 것이다. 서버가 이전의 모든 요청을 기억하게 되면 메모리 많이 사용하고 서버 부하도 증가하는 등 단점이 많잖아? 그래서 그냥 기억 안하는 거다.

비연결성 (Connectionless)

요청과 응답이 끝나면 연결을 끊는 것이다. 즉 서버와 클라이언트가 Connection을 지속하지 않는 것이다. 연결을 유지하면 자원이 계속해서 사용되지만, 유지하지 않으면 서버의 자원을 더욱 효율적으로 사용할 수 있게 되기 때문이다.
HTTP/1.0 시절에는 매 요청마다 새로 연결을 하여 느렸지만, 1.1부터는 Keep-Alive 기능이라고 연결을 잠시 유지해서 여러 요청을 보낼 수 있는 기능이 생겼다.

연결을 끊는 다면서 왜 유지하지? 라는 의문이 생길 수 있다.
차근차근 알아보자.

웹 페이지 하나를 요청한다고 생각해보자. 페이지에는 HTML, CSS, JS, 이미지 10개
이렇게 여러 자원이 있다. 그런데 HTTP/1.0은 자원 하나마다 연결 → 응답 → 종료를 반복했다.
문제는 여기서 생긴다. 새 연결을 맺을 때마다 TCP Handshake가 발생한다는 것이다.
여기서 연결은 단순한 연결이 아니다. SYN -> SYN-ACK -> ACK 이런 과정을 거치는데 자원이 20개면? 20번을 하는거다..이게 대략 1초 정도 지연이 생기기도 하는 것이다.

그래서 등장한 것이 바로 Keep-Alive다.
한 번 TCP 연결 맺고 HTML 요청, CSS 요청, JS 요청, 이미지 요청, 다 끝나면 종료
이걸 지속 연결이라고 하는 것이다.

그럼 그냥 계속 연결하면 되잖아? ➡ 아까 말했듯이 서버 자원 문제라 어쩔수 없다 이건

---

HTTP 상태 코드

• 200 : OK
• 201 : Created
• 400 : Bad Request
• 401 : Unauthoized
• 404 : Not Found
• 500 : Internal Server Error

많이 사용하는 상태코드에는 위와 같은 종류가 있는데 좀더 설명해보자면 아래와 같다.

1xx(정보) : 요청을 받았으며 프로세스를 계속 진행
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용
3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없음
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패

---

HTTP 메세지

위에 설명 했던 동작 방식과 비슷한 이야기이다.
HTTP는 우리처럼 말로 대화를 주고 받는게 아니라 정해진 구조의 메세지를 주고받는다.
메세지의 종류는 2종류가 존재한다. 요청(Request)메세지와 응답(Response)메세지

요청 메시지

브라우저가 서버에게 보내는 메세지다.

• 시작줄 (Start Line)
  • GET /users/1 HTTP/1.1
    • HTTP/1.1로 1번 사용자 정보 요청
• 헤더 (Header)
  • Host: example.com
  • Content-Type: application/json
    • 추가 정보에 대한 내용이다
    • Host → 어느 서버?
    • Content-Type → 데이터 형식
    • Authorization → 인증 정보
    • Cookie → 로그인 정보
• 바디 (Body)
  • { “name”: “Seungje”, “age”: 28 }
  • 서버에 전달할 실제 내용이다
• 전체 구조

    GET /users/1 HTTP/1.1
    Host: example.com
    Content-Type: application/json
  
    {
        "name": "Seungje",
        "age": 28
    }
  
  

응답 메세지

서버가 돌려주는 메세지다.

• 시작줄 (Start Line)
  • HTTP/1.1 200 OK
    • HTTP/1.1 → 버전
    • 200 → 상태 코드
    • OK → 설명
    • “정상 처리 완료”라는 의미
• 헤더 (Header)
  • Content-Type: application/json
  • 응답에 대한 추가 정보이다.
• 바디 (Body)
  • 실제 데이터 (JSON, HTML, IMAGE 등이 포함되어있다)

쉽게 설명하면 HTTP 메세지는 편지 형식이라 생각하면 된다.

시작줄 → 편지 제목
헤더 → 보내는 사람, 받는 사람 정보
바디 → 진짜 내용

---

HTTP 메서드

많이 들어봤을 내용이다.
HTTP 메서드의 종류는 9가지가 있는데, 하나씩 보자면

1️⃣ GET : 조회
2️⃣ POST : 요청 (주로 데이터 등록에 사용)
3️⃣ PUT : 리소스를 대체, 해당 리소스가 없으면 생성 (리소스 전체 수정)
4️⃣ PATCH : 리소스 일부 수정
5️⃣ DELETE : 리소스 삭제
6️⃣ HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
7️⃣ OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
8️⃣ CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
9️⃣TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

주로 사용하는 메서드는 1번 ~ 5번이다. 나머지 내용은 처음 봤을때 당황하면 없어보이니 한번 씩 보는 정도로 만족해보자

---

참고자료

https://okky.kr/questions/1164521

https://inpa.tistory.com/entry/HTTP-%F0%9F%8C%90-%EB%B0%B1%EC%97%94%EB%93%9C-%EB%A1%9C%EB%93%9C%EB%A7%B5-HTTP%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94#http_%EB%A9%94%EC%84%B8%EC%A7%80

https://velog.io/@sweet_sumin/HTTP-%EB%B2%84%EC%A0%84%EB%B3%84-%EC%B0%A8%EC%9D%B4-1.0-1.1-2.0-3

https://bruders.tistory.com/143