HTTP(Hypertext Transfer Protocol)
웹에서 데이터를 주고받는 서버-클라이언트 모델의 프로토콜(웹 브라우저가 서버와 통신하는 규칙)
통신 방법
- 사용자가 웹사이트를 방문하면 브라우저가 웹서버로 리소스를 요청
- 요청을 받은 웹서버는 HTML, CSS와 같은 리소스를 응답으로 돌려줌
- 클라이언트 요청과 서버의 응답 사이에 여러 프록시(Proxy) 서버를 거침
- 프록시 서버를 통해 캐시를 보관하거나 보안을 위해 서버의 IP 주소를 숨기는 등 처리
- 이 모든 통신을 안전하게 이뤄지게 하기 위해 TCP(Transmission Control Protocol) 연결을 사용
특징
- TCP/IP를 이용하는 응용 프로토콜
- HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜임(Connectionless)
(이러한 단점을 해결하기 위해 Cookie와 Session이 등장) - HTTP는 클라이언트와 서버 사이에 상태를 유지하지 않는 무상태성을 지님(Stateless)
[ Stateless 와 Connectionless 차이 ]
Stateless (무상태성)
- 필요한 상태에 대한 정보를 클라이언트가 가지고 오기 때문에 클라이언트의 요청에 어느 서버가 응답해도 상관 없음
따라서 클라이언트의 요청이 대폭 증가하면 서버를 증설해 해결할 수 있음
Connectionless (비연결성)
- 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어
연결을 유지하지 않음으로써 서버의 자원을 효율적으로 관리하고 수 많은 클라이언트의 요청에 대응할 수 있게 함
HTTP 요청과 응답
요청(Request)
- 브라우저는 아래와 같은 HTTP 요청을 서버로 보냄
- 첫 줄에는 HTTP 요청 메서드, URL 경로, HTTP 프로토콜 버전 정보가 있음
- 두 번째 줄부터 모두 HTTP 요청의 헤더인데요. key:value 쌍으로 이뤄져 있음
- 헤더는 웹사이트 도메인의 호스트, 언어, 사용자의 브라우저 등 서버가 필요한 정보를 전달
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept-Language: ko-KR
요청의 종류(Request Method)
- GET : 자료를 조회할 때 사용
- POST : 자료의 처리, 주로 데이터 등록할 때 사용
- PUT : 자료의 수정, 해당 자료가 없으면 생성
- PATCH : 자료의 일부만 수정을 요청할 때 사용
- DELETE : 자료의 삭제를 요청할 때 사용
기타 메소드 4가지
- HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
HTTP 메소드 특성 (중요)
안전성(Safe)
- 호출해도 리소스 변경이 일어나지 않는 속성
- 여기서 안전의 기준은 오직 리소스 변경 가능성이며, 외적인 요소는 포함하지 않음
- GET, HEAD를 안전한 메소드라고 볼 수 있음 (POST, PUT, PATCH, DELETE는 리소스를 변경하는 메소드이므로)
멱등성(Idempotent)
- 동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것
- 같은 행위를 여러 번 반복하더라도 같은 효과를 받으며, 서버의 상태로 동일하게 남음
- 멱등성은 요청의 결과를 보고 판단
- TimeOut 등으로 클라이언트가 서버로부터 정상 응답을 받지 못 했을 때 같은 요청을 다시 해도 되는지 판단하는 근거
- GET : 몇 번을 조회하더라도 같은 결과가 조회된다. ⇒ 회원 정보를 몇번을 조회한다고 정보가 달라지지 않음
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종 결과는 같음
- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같음
- POST : 멱등이 아니다. 두 번 호출하면 에러가 발생할수 있다. ⇒ POST로 주문을 두 번 호출하면 결제가 중복될 수 있음
캐시 가능 (Cacheable)
- 응답 결과를 캐시해 사용할 수 있는 속성임
- GET, HEAD, POST, PATCH가 캐시 가능하나, Message Body의 캐시 키의 복잡성 문제로 실제로는 GET, HEAD만 사용
응답(Response)
- 요청에 문제가 없다면 서버는 아래와 같은 응답을 돌려줌
- 첫 줄에는 HTTP 프로토콜 버전 정보와 HTTP 상태 코드가 있음
- 둘째 줄부터 보이는 key:value 쌍은 역시 모두 헤더임
- 응답의 헤더는 브라우저가 필요한 정보를 전달해줌
- 마지막으로 응답의 Body는 브라우저가 요청한 데이터
- 아래 예시에서는 HTML 데이터를 돌려주고 있음
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2023 14:28:02 GMT
Server: Apache
Content-Type: text/html
<html>
...
</html>
상태 코드(Status Code)
- 1XX (조건부 응답) : 요청을 받았으며 프로세스를 계속 진행
- 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킴
- 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 함
- 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타냄
- 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타냄
HTTP와 HTTPS의 차이점
- HTTP 통신에서 브라우저와 서버는 데이터를 일반 텍스트로 교환
- HTTP는 데이터를 암호화하지 않고 전송하기 때문에 제3자가 데이터를 가로채고 읽을 수 있음
- 보안을 강화하기 위해 HTTP는 HTTPS(Hypertext Transfer Protocol Secure)로 확장
- HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 생성
- HTTPS는 모든 요청 및 응답을 SSL(Secure Socket Layer) 및 TLS(Transport Layer Security) 프로토콜에 따라 암호화
프록시(Proxy)
클라이언트와 서버 사이에 존재하며, 중계기로서 대리로 통신을 수행하는 것을 Proxy라고 하며, 그 중계 기능을 하는 주체를 Proxy Server라고 함
종류
1. 포워드 프록시(Forward Proxy)
- 일반적인 프록시를 포워드 프록시임
- 클라이언트와 서버 사이에 위치해 요청을 중개하며, 요청과 응답은 Proxy Server를 거침
- 클라이언트를 감추는 효과가 있음
2. 리버스 프록시(Reverse Proxy)
- 포워드 프록시와 다르게 Server들이 주로 내부망으로 구성되며 프록시에게만 연결을 허용
- 서비스를 위한 보안 채널을 구축함
- 클라이언트가 서버에 직접 접근이 불가능하므로, 리버스 프록시에서 요청을 적극적으로 중계하는 로드 밸런싱 역할을 수행하기도 함
- 서버를 감추는 효과가 있음
프록시를 사용하는 이유?
- 개인정보를 보호할 수 있음
- 프록시 서버 없이 클라이언트가 서버에 요청 시 본인의 IP 주소가 노출되는데, 프록시 서버를 사용 시 서버측에서 나의 IP가 아닌 프록시 서버의 IP를 보게 됨(IP를 숨길 수 있음)
- 캐시를 사용해서 속도가 향상됨
- 프록시 서버는 웹페이지를 가져올 때 자신의 DB에 최근 데이터를 저장하는데, 이것을 Cache라고 함
- 이러한 경우, 같은 요청이 들어오면 Cache 자원을 반환하여 서비스의 속도를 높이고 대역폭도 줄일 수 있음
- 로그를 기록, 관리할 수 있음
- 서버 측에선 클라이언트의 기록대신 프록시 서버의 기록이 있지만, 프록시 서버에겐 클라이언트의 기록이 남아있음
- 어떤 IP에서 어떤 IP로 얼마나 접속해 있는지 확인할 수 있고, 특정 IP가 방문할 수 있는 웹사이트도 제한할 수 있어서 회사에서 많이 사용
- 접속을 우회할 수 있음
- 특정 사이트에서 IP를 검사해 한국에서의 접속을 차단하는 경우가 있는데, 이런 경우 프록시 서버를 사용해 접속 시 다른 나라에서 접속한 것처럼 우회할 수 있음
Proxy Chaining
클라이언트의 IP를 숨기기 위해 여러 프록시 서버를 경유하는 기술을 Proxy Chaining 이라고 함
예를 들어 Client->Proxy Server1->Proxy Server2... -> Server 처럼 사용하는 것인데, 이렇게 되더라도 프록시 서버를 계속하여 추적하면 클라이언트를 알아낼 수도 있지만 여러 국가에 접속하여 우회하면 알아내기 힘듦
[참고]
https://docs.tosspayments.com/resources/glossary/http-protocol#http%EC%99%80-https%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90
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%EC%9D%98_%EB%AC%B4%EC%83%81%ED%83%9C%EC%84%B1_stateless
https://velog.io/@younghyun/%ED%94%84%EB%A1%9D%EC%8B%9CProxy%EB%9E%80
'크래프톤 정글 - TIL' 카테고리의 다른 글
| 크래프톤 정글 5기 TIL - Day 47(CS:APP) (0) | 2024.05.07 |
|---|---|
| 크래프톤 정글 5기 TIL - Day 46 (2) | 2024.05.04 |
| 크래프톤 정글 5기 TIL - Day 44 (0) | 2024.05.03 |
| 크래프톤 정글 5기 TIL - Day 43 (0) | 2024.05.02 |
| 크래프톤 정글 5기 TIL - Day 42(키워드 정리) (1) | 2024.05.01 |
