[STAGE 2] Background(Web) - 웹 기본상식 - HTTP/HTTPS

# Background: HTTP/HTTPS

1. 인코딩 & 통신 프로토콜

(1) 인코딩

인코딩(Encoding) 표준 : 0과 1로 우리의 문자를 표현하는 일종의 약속, 대표적으로 아스키(Ascii)와 유니코드(Unicode)

    → 아스키 : 7비트 데이터에 대한 인코딩 표준

컴퓨터가 개발된 초기에는 각 문자권마다 고유의 인코딩 표준을 사용 (영어는 아스키, 한글은 CP-949, EUC-KR 등을 사용)

    → 그런데 이러한 방식은 호환성 측면에서, 국제 소프트웨어를 개발하려는 회사에 큰 부담이 됐음

이러한 어려움을 해결하고자 유니코드라는 새로운 표준이 만들어짐
→ 유니코드에서 한 문자는 최대 32개의 비트로 표현됨 (대략 42억 가지의 정보 표현 가능)

 

(2) 통신 프로토콜

웹 서버에 있는 리소스를 클라이언트가 받아 보려면..

→ 클라이언트는 웹에게 특정 리소스를 지정하여 제공해달라고 요청
→ 서버가 해당 요청을 이해 & 대응되는 동작을 통해 클라이언트에게 리소스를 반환
→ 클라이언트의 행위 : 요청(Request), 서버의 행위 : 응답(Response)

프로토콜(Protocol) = 규격화된 상호작용에 적용되는 약속
일상생활의 상호작용 : 대부분 관습 또는 에티켓이라는 형태의 느슨한 프로토콜을 따름
일상에서 사람과 사람이 통신할 때는 관습을 따르되 약간의 융통성을 발휘해도 정보를 교환하는 데 큰 문제가 발생 X

반면, 컴퓨터와 통신할 때는 비교적 엄격한 프로토콜을 사용해야 함
→ 컴퓨터가 해석의 융통성을 발휘하게 하는 것은 매우 어려움 & 오히려 통신 오류가 발생할 가능성을 높일 수 있기 때문

→ 많은 컴퓨터 통신 프로토콜은..

        각 통신 주체가 교환하는 데이터(이하 메시지)를 명확히 해석할 수 있도록 문법(syntax)을 포함함
→ 일반적으로 이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시됨

현재까지 제정된 표준 통신 프로토콜

: 네트워크 통신의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP 등

매우 많은 종류가 존재함

2. HTTP

(1) HTTP(Hyper Text Transfer Protocol)
: 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜
→ 팀 버너스 리(Team Berners-Lee)와 그의 팀이 제정한 이후, 현대 웹 서비스의 바탕이 되는 프로토콜로 자리 잡음

HTTP의 기본 메커니즘 = 클라이언트가 서버에게 요청하면, 서버가 응답하는 것
웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킴
→ 이 포트는 일반적으로 TCP/80 또는 TCP/8080
클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환

 

cf. 네트워크 포트와 서비스 포트

네트워크 포트(Network Port) = 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소
편의상, 네트워크를 설명하는 맥락에서는 네트워크를 생략하여 “포트”라고 부르기도 함

서비스 포트(Service Port) = 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트
예를 들어, HTTP가 80번 포트를 점유하고 있다면 HTTP의 서비스 포트는 80번 포트

포트로 데이터를 교환하는 방식 → 전송 계층(Transport Layer)의 프로토콜을 따름 (대표적으로는 TCP와 UDP가 있음)
→ TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 X, 반대의 경우도 마찬가지
그래서 서비스 포트를 표기할 때는 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 함
→ HTTP의 서비스 포트가 TCP/80 이라고 하면, HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 뜻

포트의 개수는 운영체제에서 정의하기 나름
→ 현대의 윈도우나 리눅스, 맥 운영체제는 0번 부터 65535번까지, 총 65536개의 같은 수의 네트워크 포트를 사용

포트 중 0번부터 1023번 포트는 잘 알려진 포트(Well-known port) 또는 특권 포트(Privileged port)라고 함
→ 문자 그대로 각 포트 번호에 유명한 서비스가 등록되어 있음
→ 대표적으로 22번 포트에는 SSH, 80에는 HTTP, 443에는 HTTPS가 할당되어 있음
잘 알려진 포트에 서비스를 실행하려면 관리자 권한이 필요함
→ 따라서 클라이언트는 이 대역에서 실행 중인 서비스들은 관리자의 것이라고 신뢰할 수 있음

(2) HTTP 메시지
: HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있음
→ 기능과 세부 구조에서는 차이가 있지만, 크게 보면 이들은 HTTP 헤드와 바디로 구성된다는 공통점이 있음

HTTP 헤드
HTTP 헤드의 각 줄은 CRLF로 구분 & 첫 줄은 시작 줄(Start-line), 나머지 줄은 헤더(Header)라고 부름
→ 시작 줄의 역할은 요청과 응답에서 큰 차이가 있음

헤드의 끝은 CRLF 한 줄로 나타냄

헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타냄

하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있음

HTTP 바디
HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말함

클라이언트나 서버에게 전송하려는 데이터가 바디에 담김

cf. CRLF란?
CRLF는 Carriage Return (CR)와 Line Feed (LF)의 조합

Carriage Return = 커서를 현재 줄의 맨 앞으로 이동시키는 문자 & Line Feed = 커서를 다음 줄로 이동시키는 문자

→ 이것들은 주로 텍스트 파일에서 줄 바꿈을 나타내는 데 사용되는 제어 문자열

→ 윈도우 운영체제에서는 줄을 종결하기 위해 CRLF를 사용 & 리눅스같은 유닉스 기반 운영체제에서는 LF만을 사용

HTTP 메시지

(3) HTTP 요청
HTTP 요청 = 서버에게 특정 동작을 요구하는 메시지

서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토 & 적절할 때만 이를 처리

시작 줄
HTTP 요청의 시작 줄 = 메소드(Method), 요청 URI(Request-URI), HTTP 버전으로 구성됨 & 각각은 띄어쓰기로 구분
→ 메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타냄

→ HTTP 표준에 정의된 메소드는 8개가 있으나, 여기서는 비교적 자주 사용되는 GET과 POST 메소드만 설명

GET은 리소스를 가져오라는 메소드

→ 이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭

→ 새로운 페이지를 렌더링하기 위해 리소스가 필요함

→ 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아옴

반대로, POST는 리소스로 데이터를 보내라는 메소드

→ 전송할 데이터는 보통 HTTP 바디에 포함됨

→ 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내짐

이 외에 요청 URI는 메소드의 대상을, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타냄

헤더와 바디
시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같음

(4) HTTP 응답
HTTP 응답 = HTTP 요청에 대한 결과를 반환하는 메시지
    → 요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status),

        그리고 클라이언트에게 전송할 리소스가 응답에 포함됨

시작 줄

HTTP 응답의 시작 줄 = HTTP 버전, 상태 코드(Status Code), 처리 사유(Reason Phrase)로 구성

    → 각각은 띄어쓰기로 구분

HTTP 버전 : 서버에서 사용하는 HTTP 프로토콜의 버전
상태 코드 : 요청에 대한 처리 결과를 세 자릿수로 나타냄
    → HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있음

    → 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류됨
처리 사유 : 상태 코드가 발생한 이유를 짧게 기술한 것

상태 코드	설명	대표 예시
1xx	요청을 제대로 받았고, 처리가 진행 중임
2xx	요청이 제대로 처리됨	200(OK) : 성공
3xx	요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함.	302(Found) : 다른 URL로 갈 것
4xx	클라이언트가 잘못된 요청을 보내어 처리에 실패했습니다.	400(Bad Request) : 요청이 문법에 맞지 않음 401(Unauthorized) : 클라이언트가 요청한 리소스에 대한 인증이 실패함 403(Forbidden) : 클라이언트가 리소스에 요청할 권한이 없음 404(Not Found) : 리소스가 없음
5xx	클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패했습니다.	500(Internal Server Error) : 서버가 요청을 처리하다가 에러가 발생함 503(Service Unavailable) : 서버가 과부하로 인해 요청을 처리할 수 없음

헤더와 바디
시작 줄을 제외한 헤더와 바디는 HTTP 메시지에서 설명한 것과 같음

 

3. HTTPS

HTTP의 응답과 요청은 평문으로 전달됨

→ 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있음

HTTPS(HTTP over Secure socket layer)

: TLS(Transport Layer Security) 프로토콜을 도입하여 이런 문제점을 보완함

→ TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화함

→ 공격자가 중간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능

→ 결과적으로 HTTP 통신이 도청과 변조로부터 보호됨

HTTPS가 제정된 초기 : 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들 위주로 HTTPS가 사용됨

→ 그러나 현재 개발되는 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세

웹 서버의 URL이 http://로 시작되면 HTTP, https://로 시작되면 HTTPS 프로토콜을 사용함