공부목적으로 다른 블로그의 글을 그대로 따라치면서 작성되었습니다. 저작권 문제 시, 비공개 처리하겠습니다
HTTP 프로토콜
- 개념
- Hyper Text Transfer Protocol
- 하이퍼 텍스트 교환 방식 (Hyper Text) -> HTML (Hyper Text Markup Language)
- 웹상에서 클라이언트와 서버간에 요청/응답(request/response) 으로 정보를 주고 받을 수 있는 프로토콜
- 특징
- 주로 HTML 문서를 주고 받는 데 쓰인다
- 주로 HTML 문서를 주고 받는 데 쓰인다
- TCP 와 UDP 를 사용하며 80번 포트를 사용한다
- 비연결(Connectionless)
- 클라이언트가 요청을 서버로 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊어진다
- 무상태성(Stateless)
- 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다
- 이전에 요청한 결과를 갖고있지 않는다
HTTPS 프로토콜
- 개념
- Hyper Text Transfer Over Secure Socket Layer ( 또는 HTTP over TLS, 또는 HTTP over SSL 이라고도 불린다)
- 웹 통신 프로토콜인 HTTP 에 보안을 강화한 프로토콜이다
- HTTP 프로토콜에 데이터 암호화가 추가된 프로토콜
- 특징
- HTTPS의 기본 TCP/IP 포트로 443 포트를 사용
- HTTPS 는 socket 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화하는 SSL 이나 TLS 프로토콜을통해 세션 데이터를 암호화한다
- TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것이다
- 두 프로토콜으 주요 목표는 기밀성(사생활 보호=개인정보), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공한다
- 데이터의 적절한 보호를 보장한다
- 보호의 수준은 개발자의 웹 구현능력과 암호화 알고리즘에 달리게 된다
- https 프로토콜을 적용하는 이유는 클라이언트와 서버간의 통신 중 데이터를 탈취했을 때 데이터를 알아볼 수 없게 보안하기 위함이다
- 사용자의 데이터를 공개키 암호화(공개키를 얻은 인증된 사용자)
- 서버로 전송 (데이터를 가로채도 개인키가 없으므로 복호화할 수 없다)
- 서버의 개인키를 통해 복호화 하여 요청을 처리한다
- HTTPS 의 장단점
- 장점
- 네트워크 상에서 열람, 수정이 불가능하므로 안전하다
- 단점
- 암호화를 하는 과정이 웹 서버에 부하를 준다
- HTTPS 는 설치 및 인증서를 유지하는 추가 비용이 발생 (유료)
- HTTP 에 비해 느리다 (오늘날에는 크게 느껴지지 않는다)
- 인터넷 연결이 끊긴 경우 재인증 시간이 소요된다
- HTTP 는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있다
- 그러나 HTTPS 의 경우에는 socket(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 socket 도 끊어져서 다시 HTTPS 인증이 필요하다
 |
 |
HTTP(S) 요청 응답 헤더
- HTTP 헤더 내 일반 헤더 (General Header 항목)
- 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의 (기본적인) 헤더 항목
- 주요 항목들
- Date : HTTP : 메시지를 생성한 일 시
- Connection : 클라이언트와 서버 간 연결에 대한 옵션 설정
- Connection : close -> 현재 http 메시지 직후 tcp 접속을 끊는다는 것을 알림
- Connection Keep-Alive -> 현재 tcp 커넥션을 유지
- cache-control
- pragma
- trailer
- HTTP 헤더 내 엔티티/개체 헤더 (Entity Header) 항목
- 콘텐츠, 본문, 리소스
- Content-Type
- Content-Encoding
- Content-Length
- ....
- 콘텐츠, 본문, 리소스
- HTTP 헤더 내 요청 헤더 (Request Header) 항목
- Host : 호스트명 또는 호스트명+포트
- User-Agent : 클라이언트명 (크롬, 사파리 등..)
- Cookie : 모든 쿠키 정보
- Referer : 이전 페이지 주소
- If-Modified-Since : 제시한 일시 이후로만 변경된 리소스를 취득 요청
- Authorization : 인증 토큰 담는 곳
- Origin
- 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄
- 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
- 응답 헤더의 Access-Control-Allow-Origin와 관련
- HTTP 헤더 내 응답 헤더 (Response Header) 항목
- 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답한다.
- 주요 항목들
- Server: 서버 소프트웨어 정보
- Accept-Range
- Set-Cookie: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
- Expires: 리소스가 지정된 일시까지 캐시로써 유효함
- Age: 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 알려줌(초 단위)
- ETag: HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
- Proxy-authenticate
- Allow: 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타냄
- 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목
- OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
- Allow: GET,HEAD => 웹 서버측이 제공 가능한 HTTP 메서드는 GET,HEAD 뿐임을 알림 (405 Method Not Allowed 에러와 함께)
- 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목
- Access-Control-Allow-Origin: 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
- 서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
- Access-Control-Allow-Origin: www.zerocho.com
- 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
- Access-Control-Allow-Origin: *
- 만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
- 유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.
스프링에서는 위와 같이 해당 헤더를 설정하여 요청을 허용할 주소를 명시해준다
HTTP 와 HTTPS 동작 과정
HTTP 동작 과정
서버 접속 -> 클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트 -> 연결 종료
①. URL 을 통한 서버 접속 (http://www.naver.com)
②. DNS 서버에 의해 웹 서버의 호스트 이름을 IP 주소로 변경 (http://www.naver.com -> http://123.4567.12:8080)
③. 웹 서버와 연결 시도 (3 way handshaking) -> 핸드 쉐이킹 거친 후 서버와 연결완료
④. 클라이언트가 서버에게 요청=Request (GET)
- HTTP Request Message = Request Header + 빈 줄 + Request Body
- Request Header
- 요청 메소드 + 요청 URI + HTTP 프로토콜 버전
- GET /background.png HTTP/1.0 POST / HTTP 1.1
- Header 정보(key-value 구조)
- 빈 줄
- 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
- Request Body
- GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 바디 미포함
- 데이터 업데이트 요청과 관련된 내용 (HTML 폼 콘텐츠 등)
⑤. 서버가 클라이언트에게 데이터 응답
- HTTP Response Message = Response Header + 빈 줄 + Response Body
- Response Header
- HTTP 프로토콜 버전 + 응답 코드 + 응답 메시지
- ex. HTTP/1.1 404 Not Found.
- Header 정보(key-value 구조)
- 빈 줄
- 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
- Response Body
- 응답 리소스 데이터
- 201, 204 상태 코드는 바디 미포함
HTTP 프로토콜에서 사용한다는 TCP 와 UDP 에 대한 이해
HTTP 는 비연결성이다. 하지만 TCP 는 연결성이다
둘 다 프로토콜이고 HTTP 는 TCP 기반으로 만들어진 프로토콜이라고 한다
HTTP 는 OSI 7 계층 중 Application Layer 이며, TCP 와 UDP 는 Trasnfer Layer 이다
때문에 TCP 로 요청 (request) 와 응답(response) 은 하나의 연결성을 가지고 있다
그리고 서버로 부터 응답이 된 후에는 HTTP 프로토콜 특성상 연결을 끊어버린다
연결을 끊어버렸기 때문에 상태를 갖지 않고 있어 stateless (무상태성) 인 것 이다
통은 TCP 기반으로 socket 통신하며 Streaming 서비스를 해야하는 경우 UDP 기반 socket 통신을 사용한다
HTTP 버전 1 보다는 HTTP 버전 2 가 빠르며 HTTP 버전 3 도 있는데 HTTP 버전 3은 UDP 기반 통신이다
공개키와 대칭키 간단 요약
- 대칭키 암호화
- 하나의 비밀키로 암호화 복호화 (클라이언트 & 서버 같은 비밀키 사용)
- 보안에 취약
- 속도가 공개키보다 빠름
- 공개키 암호화 = 비대칭키 암호화 > 예) SSL
- 공개키와 비밀키를 갖으며 공개키로 암호화 하며, 비밀키로 복호화를 진행 (클라이언트 암호화, 서버 복호화)
- 보안에 강함
- 속도는 대칭키보다 느림
- 공개키를 통해 누구나 암호화 할 수 있지만 복호화는 비밀키를 갖고 있는 서버만 가능하게 된다
HTTPS 암호화 방식
공개키 암호화 방식과 대칭키 암호화 방식의 장점을 활용해 하이브리드 사용 데이터를 대칭키 방식으로 암복호화하고, 공개키 방식으로 대칭키 전달
OKKY 참고
'∞. 기술 면접 > 2. 네트워크' 카테고리의 다른 글
| 06. 기술면접 - 네트워크 - 쿠키, 세션, 로컬 스토리지, 세션 스토리지 (0) | 2021.09.30 |
|---|---|
| 05. 기술면접 - 네트워크 - GET 과 POST (0) | 2021.09.30 |
| 04. 기술면접 - 네트워크 - CORS (1) | 2021.09.30 |
| 02. 기술면접 - 네트워크 - TCP & UDP (0) | 2021.09.28 |
| 01. 기술면접 - 네트워크 - OSI 7 계층 (0) | 2021.09.27 |