[네트워크] HTTP/HTTPS

1. HTTP(Hyper Text Transfer Protocol)

• HTTP(Hyper Text Transfer Protocol)란 웹상에서 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜
• 데이터는 HTML뿐만이 아닌 평문, JSON 등 다양한 포맷이 가능
• 서버/클라이언트 간의 연결을 유지하기 위한 리소스를 줄여 많은 연결을 할 수 있도록 비연결적인 특징을 갖도록 설계
• 81번 포트를 기본적으로 사용

TCP/IP 위에서 작동

• HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동
• TCP/IP 위에서 작동하기 때문에 연결의 시작과 끝은 TCP 연결과 해제가 이루어짐
• TCP/IP랑은 다르게 무상태성이며 비연결성 특성을 가짐

HTTP의 무상태성(Stateless)

• 서버는 응답 메세지를 반환한 후에 초기 상태로 돌아감
• 서버는 클라이언트의 상태를 따로 저장하지 않음(상태가 없는 프로토콜)
• 서버와 클라이언트는 데이터를 주고 받기 위한 각각의 데이터 요청을 서로 독립적으로 관리
• 그래서 다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능 상의 이점이 생김
• 따로 서버가 클라이언트이 상태를 관리하기 위해서는 쿠키나 세션을 사용해야 함

2. HTTP Request 구조

Start Line (시작줄)

• 해당 request 가 어떤 action 을 의미하는지 정보를 담음
  • HTTP 메소드 : 요청의 의도를 담고있는 메소드로, GET, POST, PUT, DELETE 등이 있음
  • Request Target : 요청이 전송되는 목표 주소
  • HTTP version : version에 따라 요청 메시지 구조나 데이터가 다를 수 있기 때문에 version을 명시

Headers

• HTTP Request 그 자체에 대한 정보
• key : value 형태로 이루어져 있다.
• Header의 경우 Request, Response 각각이 쓰는 항목 외에 공통 항목이 있지만, 여기선 우선 Request Header에 있는 정보만 설명하겠다.
  • Host : 요청하려는 서버 호스트 이름과 포트번호
  • User-agent : 클라이언트 프로그램 정보, 이 정보를 통해 서버는 클라이언트 프로그램(브라우저, 기기 등)에 맞는 최적의 데이터를 보낼 수 있음
  • Referrer : 바로 직전에 머물렀던 웹 링크 주소
  • Accept : 클라이언트가 처리 가능한 미디어 타입 종류 나열
  • If-Modified-Since : 여기에 써여진 시간 이후로 변경된 리소스 취득하고, 페이지가 수정되었으면 최신 페이지로 교체
  • Authorization : 인증 토큰을 서버로 보낼 때 쓰이는 항목
  • Origin : 서버로 POST 요청을 보낼 때 요청이 어느 주소에서 시작되었는지 나타내는 값으로, 요청을 보낸 주소와 받는 주소가 다르면 CORS(Cross-Origin Resource Sharing) 에러가 발생
  • Cookie : 쿠키 값이 key : value 로 표현

Body

• HTTP Request가 전송하는 데이터를 담고있는 부분이다. 전송하는 데이터가 없을 수 있음
• 보통 POST 요청일 경우, HTML 폼 데이터가 포함되어 있다.

Request Method

GET	- 소스를 검색하고, 반환받기 위해 사용되는 메소드 - 원하는 정보를 서버에 요청할 때 쓰임 - (일반적으로) 리소스의 위치를 URL에서 쿼리로 표현하기 때문에 RequestBody가 없음
HEAD	- 서버의 각종 정보를 확인하기 위해 사용되는 메소드
POST	- 요청된 자원을 생성하기 위해 사용되는 메소드 - POST로 정보를 전송하면 URL에 파라미터가 나타나지 않으므로 각종 데이터를 전송하는데 쓰임
PUT	- 요청된 자원을 수정하기 위해 사용되는 메소드
PATCH	- 요청된 자원을 수정하기 위해 사용되는 메소드라는 점에서 PUT과 같음 - 해당 자원 전체를 수정하는 PUT과는 다르게 PATCH는 해당 자원의 일부 부분을 수정한다.
DELETE	- 요청된 자원을 삭제하기 위해 사용되는 메소드 - 클라이언트에서 서버의 자원을 삭제할 수 있도록 허가하는 것은 매우 위험 - 현실적으로 사용될 일이 거의 없고, 대부분의 서버는 이 메소드를 비활성화시킴
TRACE	- 루프백 메시지를 호출하기 위해 테스트용으로 사용되는 메소드
OPTION	- 웹서버에서 지원하는 메소드를 알기 위해 사용되는 메소드
CONNECT	- 프록시 기능을 요청할 때 사용되는 메소드

3. HTTP Response 구조

Status line

• HTTP Response의 상태를 간략하게 나타내주는 부분
• HTTP Response의 status line또한 3가지 부분으로 구성
  • HTTP version
  • Status Code : 상태 코드
  • Status Text : 상태 메세지

Headers

• Request의 headers와 동일하다.
• 다만 response에서만 사용되는 header 값들이 있다.
• 예를 들어, User-Agent 대신에 Server 헤더가 사용된다.

body

• Response의 body와 일반적으로 동일하다.
• Request와 마찬가지로 모든 response가 body가 있지는 않다.
• 데이터를 전송할 필요가 없을경우 body가 비어있게 된다.

상태 코드 목록

분류	상태 코드	상태 설명	내용
성공	200	OK	요청을 성공함
클라이언트 오류	401	unauthorized	인증되지 않음
	403	Forbidden	액세스가 허용되지 않음
	404	Not Found	요청한 리소스를 찾지 못함
	408	Request Timeout	요청 시간을 초과함
서버 오류	500	Internal Server Error	서버 내부에서 오류가 발생함
서버 오류	503	Service Unavailable	서비스를 일시적으로 사용할 수 없음

4. HTTPS(Hyper Text Transfer Protocol Secure)

• HTTPS는 HTTP에 데이터 암호화가 추가된 프로토
• HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원

대칭키 암호화와 비대칭키 암호화

• HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용
• 대칭키 암호화
  • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
  • 키가 노출되면 매우 위험하지만 연산 속도가 빠름
• 비대칭키 암호화
  • 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
  • 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
  • 공개키: 모두에게 공개가능한 키 / 개인키: 나만 가지고 알고 있어야 하는 키
    • 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화 가능
      -> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
    • 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화 가능
      -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성 보장

5. HTTPS의 동작 과정

• HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻음
• HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환
• 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어짐
• 문제는 이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐 인데, 이 과정에서 비대칭키가 사용된다.
• 즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것

HTTPS 연결 과정이 성립되는 흐름

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함
2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줌
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함

6.  HTTP와 HTTPS

• HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있음
• 하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느림
  (물론 오늘날에는 거의 차이를 못느낄 정도)
• 또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용 발생
• 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용