HTTP

docu·2023년 3월 27일

UDP WAS http ip tcp 웹서버

HTTP

데이터를 주고 받는 양식을 정의한 "통신 규약"중 하나
(통신 규약: Protocol)

NETWORK 창 살펴보기

Headers

General: 브라우저에서 서버로 보낸 Request 데이터
Request Headers: 브라우저에서 서버로 보낸 Request 데이터
Response Headers: 서버가 웹 페이지 데이터와 함께보낸 추가 데이터

Response

이것은 서버에서 여러분의 브라우저로 반환해준 웹 페이지를 그려주기 위한 데이터

HTTP 구성요소

1. Method

GET, POST

2. Header (추가 데이터, 메타 데이터)

브라우저가 어떤 페이지를 원하는지
요청 받은 페이지를 찾았는지
성공적으로 찾았는지

3. Payload (데이터, 실질적인 데이터)

서버가 응답을 보낼 때에는 항상 Payload를 보낼 수 있다
클라이언트(브라우저)가 요청을 할 때에도 Payload를 보낼 수 있다
"GET method를 제외하곤 모두 Payload를 보낼 수 있다" 는게 HTTP에서의 약속
추가적으로 DELETE method에서 Payload를 보낼수있지만, 보통 많은 경우에 Payload를 보내지않고있다

⬇️[해치지 않는 웹] 1. 웹 동작 방식
웹 클라이언트 =request=> 웹서버 =WAS=> DB =WAS=> 웹서버 =response=> 웹클라이언트

웹클라이언트 : 사용자가 웹에 접근하는 프로그램
- 크롬 등의 웹브라우저를 웹클라이언트라고함
웹서버: 웹페이지, 사이트 또는 앱을 저장하는 프로그램
- 클라이언트에서 url 주소의 메인페이지를 보내달라 요청하면, 서버는 확인 후 페이지를 만드는데 필요한 html,css,js 등을 클라이언트에게 보내줌
- 아파치 웹서버, GWS, IIS 등
WAS : 웹 어플리케이션 서버
- 사용자 컴퓨터나 장치에 웹 어플리케이션을 수행해주는 미들웨어
- 아파치 톰캣, 레진, 제이런 등
- 주문을 확인하고 역할을 분배하는게 웹서버, 실제로 요리하는 요리사가 WAS
- 로직 수행하다가 DB접근이 필요하면 SQL 질의를 통해 데이터 요청하고 DB가 응답을 보냄
DB : 데이터 정보를 저장

⬇️[해치지 않는 웹] 2. http 메시지
클라이언트가 서버에 요청하는 메시지가 Request Message,
클라이언트의 요청을 해석한 서버가 응답하는 메시지가 응답 메시지 Response Message
요청 메시지(Request Message)
1. 요청 라인 (Request Line)

메서드(어떻게) : 클라이언트가 무엇을, 어떻게 처리하고자 한다 (GET, POST, PUT, DELETE)
경로(무엇을) : 메서드를 참고하여 수행할 대상, 가져오려는 리소스의 경로
프로토콜 버전 : HTTP 프로토콜의 버전. 1.1버전과 보안성을 강화한 2버전이 있음

요청 헤더 (Request Headers)

서버에 대한 추가적인 정보
호스트의 정보, 접속 중 사용자의 정보, 열려고하는 페이지의 정보

공백 라인 (Empty Line)

헤더와 본문 구분

요청 메시지 본문 (Request Message Body)

필수 요소 아님
POST처럼 새로운 자원을 추가하는 경우 본문에 작성하여 전달

응답 메시지(Request Message)
클라이언트 요청에 대한 서버의 답변

응답 라인 (Request Line)

프로토콜 버전
상태코드
100번대(조건부 응답): 요청 받았으며 작업 계속
200번대(성공): 정상적으로 요청 수행했을때
300번대(리다이렉션 완료): 클라이언트가 요청을 마치기 위해 추가동작을 취해야할 때
400번대(요청 오류): 클라이언트의 요청에 오류가 있을때
500번대(서버 오류): 서버가 들어온 요청을 수행하지 못했을때

응답 헤더 (Request Headers)

가져온 리소스
HTML이라면 태그 형태의 코드, 이미디나 동영상이면 그에 맞는 코드

공백 라인 (Empty Line)
응답 메시지 본문 (Request Message Body)

⬇️[해치지 않는 웹] 3. 프록시 서버

프록시(proxy)

사전적 의미: 대리인
클라이언트와 서버 사이에서 HTTP 메시지를 대신 전달하는 중계 기능

프록시 서버의 특징

클라이언트와 서버가 주고 받은적 있는 데이터의 사본
이전과 동일한 데이터를 요청하는 경우 서버를 거치지 않고 프록시에서 캐싱해둔 데이터를 반환하여 전송 시간을 줄일 수 있음
IP, 쿠키 등 HTTP 메시지에 신원을 확인할 수 있는 정보들을 제거하여 익명성 보호
유해 사이트에서 IP 추적 당하지 않게 우회하기 위한 용도로 사용된다는 문제점

프록시 서버의 유형

하나의 프록시 서버는 아래의 두가지 기능을 모두 수행할 수 있음

포워드 프록시 : 서버의 메시지를 클라이언트에게 전달 (forward 앞, 클라이언트로)
리버스 프록시: 클라이언트의 요청을 다수의 서버에 분배하여 전달. 어떤 서버에게 클라 요청을 전달하면 좋을지 확인

via 헤더

메시지가 1개 이상의 프록시, 게이트웨이를 지나갈 시 via 목록 끝에 정보가 추가됨
최종으로 나열된 목록으로 클라이언트와 서버 사이의 중계기를 추적할 수 있다

⬇️[해치지 않는 웹] 4.DNS
IP (Internet Protocol)

인터넷 장치 각각을 식별할 수 있는 고유한 주소
IP4와, IP4의 주소 고갈 문제를 해결하기 위해 생긴 IP6가 있음
도메인
외우기 힘든 IP 대신 사람이 기억하기 쉽게 만든 인터넷 주소
도메인: https://brunch.co.kr
URL: https://brunch.co.kr/@vivid8822
DNS
Domain Name System: 도메인 주소를 IP주소로 변환해줌
DNS서버, 네임서버 : 변환 시스템을 운영하고 있는 서버
DNS서버에 요청이 들어오면 도메인 주소와 연결되어있는 IP주소를 찾아 응답

⬇️[해치지 않는 웹] 4.IP

IP4: 총32비트, 2의 32제곱, 43억개의 고유주소 -> 고갈문제 대두
IP6: 128비트, 거의 무한
"새로운 IP체계쓰자" vs "이미 쓰고있는거 아껴쓰자"
주소체계 전환 낮은 이용률
기존 IP4 고갈 지연 시키면서 통신 품질에 영향 없는 방안: 사설 IP주소와 공인 IP주소로 분리

사설IP주소와 공인IP주소
라우터 : 건물, 고유한 주소인 공공 IP주소를 가짐
개인기기 : 건물 내 가구들, 하나의 라우터 영역에서 각자를 구분하기 위한 사설 주소를 가짐
WAN(Wide Area Network) : LAN을 연결한 광역 네트워크
LAN(Local Area Network) : 라우터 내에서 PC, 스마트폰 등의 기기들이 연결된 지역 네트워크
-> 라우터에 여러 대의 기기를 연결함으로써 개인 PC에는 일일이 고유주소를 부여하지 않아도됨

공인: what is my ip
사설: 커맨드창에 ifconfig

NAT(network address translation): 라우터는 네트워크 주소 변환 기능을 탑재함.
라우터의 NAT기능으로 개인PC의 호스트 주소를 공인 IP로 변경하여 유투브 서버로 전달

⬇️ TCP
패킷

데이터 전송 시 패킷이라는 작은 조각으로 쪼개어 주고받음.
다양한 경로를 사용하여 이동 가능하고, 하나의 회선이 끊겨도 다른 패킷들이 안정적으로 들어올 수 있다.
TCP(Transmission Control Protocol)
데이터가 정확히 들어왔는지에 집중하는 규약
IP(비연결형)는 데이터를 정확한 주소로 전달하는 데에 목적, TCP(연결형, 수신자와 서로 연결된 상태인지 주기적으로 확인)는 데이터를 손실없이 안전하게 전달하는 것을 목적으로함
"데이터에 대한 요청" => "요청받아 보내야하는 컴퓨터의 TCP 패킷으로 잘라 IP에 전달" => "IP는 패킷을 받아 주소 해석하고 경로 결정하여 목적지로 전송" => "받는쪽 IPsms 패킷 주소가 내 주소와 일치하는지 확인하고 맞으면 받는쪽 컴의 TCP로 전달" => "TCP는 패킷모아 데이터 재조립"
TCP는 3 way handshake 기법을 통해 송신자와 수신자가 연결된 상태인지 확인한뒤 데이터 주고 받는다
전송속도가 느리다는 단점이 있음
유사한 역할을 수행하지만 속도는 빠른 UDP 프로토콜(연결 과정 없이 보내는 쪽이 일방적으로 데이터 전송, 온라인게임이나 VoIP라는 음성 데이터 주고 받을 시 사용)

⬇️ 그림으로 쉽게 보는 HTTP 변천사
HTTP 0.9
HTTP 1.0 : 문서화 시작, 헤더 등장
HTTP 1.1 (1997) : 한번 TCP 연결을 맺으면 끊지 않고 유지, 한번에 여러개의 요청 보내게 함(Pipelining)
HTTP 2 : 이전 요청에 대한 응답 대기하지 않고 뒤의 응답 받을 수 있도록, 한번의 요청으로도 여러 응답 가능, 클라이언트가 요청하지 않아도 미리 리소스 푸시하여 더 높은 성능과 빠른 속도 보장 (텍스트 형식이었던 HTTP 메시지를 바이너리 형태로 캡슐화 하였기 때문에)
오래된 프로토콜인 TCP 위에 동작한다는게 단점
HTTP 3: QUID(Quick UDP Internet Connection), TCP가 아닌 UDP 위에서 동작하되 QUIC로 중간에 데이터 손실이 발생해도 개별적으로 재전송할 수 있게하여 신뢰성까지 개선

⬇️웹프로그래밍 스터디 - 1.HTTP 따라잡기(1)