📌 Background : Web Resource
웹(Web)이란 HTTP를 이용하여 정보를 공유하는 서비스이다. 여기서 HTTP란 웹상에서 서로 통신을 하기 위해 정해둔 일종의 규칙이다.
웹 서버(Web Server): 정보를 제공하는 주체웹 클라이언트(Web Client): 정보를 받는 이용자
웹에서 처리하는 정보 자산들이 많아짐에 따라 이들을 안전하게 보관하고 처리해야 할 필요성도 함께 증가했다. 고객의 개인 정보들이 웹을 통해 서버로 전달되는데, 이러한 정보들이 안전하게 보호되지 않는다면 심각한 피해를 야기할 수 있다. 그렇기에 웹을 통한 정보의 교환 과정에서 이러한 민감한 정보들이 유출되거나 악용되지 않도록 보호하는 웹 보안의 중요성이 대두하고 있다.
현재의 웹 서비스는 이용자의 요청을 해석하고 가공하여 필요한 정보와 기능을 제공하는 능동형 서비스에 가깝다. 이러한 서비스 구조에서, 이용자의 요청을 받는 부분을 프론트엔드(Front-end), 요청을 처리하는 부분을 백엔드(Back-end)라고 부른다.
🚩 웹 리소스
프론트엔드는 이용자에게 직접 보여지는 부분으로, 웹 리소스(Web Resource)라는 것으로 구성된다. 웹 리소스란 웹에 갖춰진 정보 자산으로, 페이지가 보여주고 있는 정보들은 모두 웹 리소스에 명시되어 있다.
모든 웹 리소스는 고유의 Uniform Resource Indicator (URI)를 가지며, 이를 이용하여 식별된다. 웹의 프론트엔드를 구성하는 대표적인 웹 리소스들은 다음과 같다.
🔹 대표적인 웹 리소스들
Hyper Text Markup Language (HTML): 웹 문서의 뼈와 살을 담당한다. 태그와 속성을 통한 구조화된 문서 작성을 지원한다.Cascading Style Sheets (CSS): 웹 문서의 생김새를 지정한다. 웹 리소스들의 시각화 방법을 기재한 스타일 시트로, 브라우저는 이를 참고하여 웹 문서를 시각화한다.JavaScript (JS): 웹 문서의 동작을 정의한다. 이용자가 버튼을 클릭했을 때 어떻게 반응할지, 이용자가 데이터를 입력하면 어디로 전송할지 등을 JS로 구현할 수 있다. JS는 이용자의 브라우저에서 실행되는데, 클라이언트가 실행하는 코드라고 하여 Client-Side Script라고도 부른다.
🚩 웹 클라이언트와 서버의 통신
웹 서비스의 통신 과정을 간략화하면 다음과 같다.
- (클라이언트) 브라우저를 이용하여 웹 서버에 접속
- (클라이언트) 브라우저는 이용자의 요청을 해석하여 HTTP 형식으로 웹 서버에 리소스를 요청
- (서버) HTTP로 전달된 이용자의 요청 해석
- (서버) 해석한 요청에 따라 적절한 동작 수행
- (서버) 이용자에게 전달할 리소스를 HTTP 형식으로 전달
- (클라이언트) 브라우저는 서버에게 응답 받은 웹 리소스를 시각화하여 이용자에게 제공
📌 Background : HTTP
🚩 인코딩
컴퓨터의 모든 데이터는 0과 1로 구성된다. 0과 1로 문자를 표현하는 것도 일종의 약속 덕분이며, 이러한 약속들을 특별히 인코딩(Encoding) 표준이라 부르는데, 대표적으로 아스키(Ascii)와 유니코드(Unicode)가 있다.
인코딩을 이용하면 우리의 문장을 컴퓨터에 저장하고, 표현할 수 있다. 그리고 네트워크를 이용하면 인코딩한 정보를 다른 사람들과 쉽게 교환할 수도 있다.
🔹 아스키(Ascii)
아스키는 7비트 데이터에 대한 인코딩 표준이다. 이를 활용하면 알파벳과 특수 문자 등을 표현할 수 있다. 컴퓨터가 개발된 초기에는 각 문자권마다 고유의 인코딩 표준을 사용했다. 영어는 아스키, 한글은 CCP-949, EUC-KR 등을 사용했다. 이러한 방식은 호환성 측면에서 어려움이 존재했다. 이러한 어려움을 해결하고자 유니코드가 탄생한 것이다.
🔹 유니코드(Unicode)
'Uni(하나의)'라는 접두사가 나타내듯, 유니코드는 모든 언어의 문자를 하나의 표준에 담겠다는 목표로 제정되었다. 유니코드에서 한 문자는 최대 32개의 비트로 표현된다. 32비트로 표현할 수 있는 정보의 가짓수는 2^32, 대략 42억개이다. 문자 이외에 각종 이모지들도 유니코드에 포함되고 있다.
🚩 통신 프로토콜
웹 서버에 있는 리소스를 클라이언트가 받아보려면, 클라이언트는 웹에게 특정 리소스를 지정하여 제공해달라고 요청해야 한다. 그러면 서버가 해당 요청을 이해하고, 대응하는 동작을 통해 클라이언트에게 리소스를 반환한다. 여기서 클라이언트의 행위를 요청(Request), 서버의 행위를 응답(Response)이라고 한다.
요청과 응답은 상호작용으로, 이런 행위는 어느 정도 약속되어 있다. 프로토콜(Rrotocol)은 이러한 규격화된 상호작용에 적용되는 약속을 이른다. 컴퓨터와 통신할 때는 비교적 엄격한 프로토콜을 사용한다. 많은 컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터(메시지)를 정확히 해석할 수 있도록 문법(Syntax)을 포함한다. 일반적으로 이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시하게 된다.
현재까지 제정된 표준 통신 프로토콜에는 많은 종류가 있다. 그중 하나는 HTTP로 이 글에서 다루고 있다.
TCP/IP: 네트워크 통신의 기초가 됨.HTTP: 웹 애플리케이션이 사용함.FTP: 파일을 주고받을 때 사용함.
🚩 HTTP
HTTP(Hyper Text Transfer Protocol)란 서버와 클라이언트의 데이터 교환을 '요청'과 '응답' 형식으로 정의한 프로토콜이다. HTTP의 기본 메커니즘은 클라이언트가 서버에게 요청하면, 서버가 응답하는 것이다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환한다.
🚩 HTTP 메시지 - 헤드, 바디
HTTP 메세지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있다. 이들은 HTTP 헤드와 바디로 구성된다는 공통점이 있다.
🔹 HTTP 헤드
HTTP 헤드의 각 줄은 CRLF로 구분되며, 첫 줄은 시작 줄(Start-line), 나머지 줄은 헤더(Header)라고 부른다. 헤드의 끝은 CRLF 한 줄로 나타낸다.
CRLF: CRLF는Carriage Return (CR)과Line Feed (LF)의 조합을 나타낸다. CR과 CF는 주로 텍스트 파일에서 줄 바꿈을 나타내는 데 사용하는 제어 문자열이다. 윈도우 운영체제에서는 줄을 종결하기 위해 CRLF를 사용하고, 리눅스 같은 유닉스 기반 운영체제에서는LF만을 사용한다.Carriage Return (CR): 커서를 현재 줄의 맨 앞으로 이동시키는 문자Line Feed (LF): 커서를 다음 줄로 이동시키는 문자
시작 줄의 역할은 요청과 응답에서 큰 차이가 있기에 뒤에서 기술하도록 하겠다. 헤더는 필드와 값으로 구성되며 HTTP 메시지 또는 바디의 속성을 나타낸다. 하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있다.
🔹 HTTP 바디
HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 바디에 담긴다.
🚩 HTTP 요청
HTTP 요청은 서버에게 특정 동작을 요구하는 메시지다. 서버는 해당 동작의 실현 가능성, 요청할 권한 존재 여부 등을 검토하고, 적절할 때만 이를 처리한다.
🔹 시작 줄
HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성된다.
🔹 메소드(Method)
메소드는 URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타낸다. HTTP 표준에 정의된 메소드는 8개가 있으나, GET과 POST 메소드만 다루겠다.
🔸 GET
GET은 리소스를 가져오라는 메소드이다. 이용자가 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아온다.
🔸 POST
POST는 리소스로 데이터를 보내라는 메소드이다. 전송할 데이터는 보통 HTTP 바디에 포함된다. 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성한 글 등이 POST로 서버에 보내진다.
🚩 HTTP 응답
HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지이다. 요청을 수행했는지, 하지 않았는지, 안 했다면 그 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함된다.
🔹 시작 줄
HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성된다.
HTTP 버전: 서버에서 사용하는 HTTP 프토콜의 버전을 나타낸다.상태 코드(Status Code): 요청에 대한 처리 결과를 세 자릿수로 나타낸다.처리 사유(Reason Phrase): 상태 코드가 발생한 이유를 짧게 기술한 것이다.
🔸 RFC 2616
HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있다. 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류된다. 404(Not Found)와 같은 코드들이 이에 속한다.
🚩 포트(Port)
(포트의 정의는 아래 '네트워크 포트' 부분에서 간략하게 정리해두었다.)
포트의 개수는 운영체제에서 정의하기 나름이다. 그러나 현대의 윈도우나 리눅스, 맥 운영체제는 0번부터 65535번까지, 총 65536개의 같은 수의 네트워크 포트를 사용한다.
포트 중 0번부터 1023번 포트는 잘 알려진 포트(Well-known Port) 또는 특권 포트(Privileged port)라고 한다. 문자 그대로 각 포트 번호에 유명한 서비스가 등록되어 있다. 대표적으로 22번 포트에는 SSH, 80에는 HTTP, 443에는 HTTPS가 할당되어 있다. 잘 알려진 포트에 서비를 실행하려면 관리자 권한이 필요하다. 따라서 클라이언트는 이 대역에서 실행 중인 서비스들은 관리자의 것이라고 신뢰할 수 있다.
🔹 네트워크 포트(Network Port)
네트워크 포트(Network Port)란 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소를 의미한다. 포트에는 항구라는 의미가 있는데, 클라이언트가 서버의 포트에 접근하여 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보내는 장면을 연상하면 포트의 기능을 이해하기 쉽다. 편의상, 네트워크를 설명하는 맥락에서는 네트워크를 생략하여 "포트"라고 부르기도 한다.
🔹 서비스 포트(Service Port)
서비스 포트(Service Port)는 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트이다. 예를 들어, HTTP가 80번 포트를 점유하고 있다면 HTTP의 서비스 포트는 80번 포트가 된다.
🔹 TCP와 UDP
포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따른다. 전송 계층은 프로토콜 내에서 송신자와 수신자를 연결하는 통신 서비스를 제공하는 계층이다. 이러한 전송 계층에서 사용하는 프로코콜이 바로 TCP와 UDP이다.
TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 않는다. 반대의 경우도 마찬가지이다. 그래서 서비스 포트를 표기할 때는 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 한다. 예를 들어, HTTP의 서비스 포트가 TCP/80이라고 하면, HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 뜻이다.
🔸 TCP
TCP(Transmission Control Protocol)은 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜이다. 일반적으로 TCP와 IP가 함께 사용되는데, IP가 데이터의 전송을 처리한다면, TCP는 패킷 추적 및 관리를 하게 된다. 연결 지향형인 TCP는 3-way handshaking이라는 과정을 통해 연결 후 통신을 시작하며, 흐름 제어와 혼잡 제어를 지원하며 데이터의 순서를 보장한다.
흐름 제어: 보내는 측과 받는 측이 데이터 처리속도 차이를 조절해주는 것혼잡 제어: 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지하는 것
🔸 UDP
UDP(User Datagram Protocol)는 비연결형 프로토콜로써, 인터넷상에서 서로 정보를 주고받을 때 정보를 보낸다는 신호나 받는다는 신호 절차를 거치지 않고 보내는 쪽에서 일방적으로 데이터(비신뢰성 데이터)를 전달하는 통신 프로토콜이다. TCP와는 다르게 연결 설정이 없으며, 혼잡 제어를 하지 않기 때문에 TCP보다 전송 속도가 빠르다. 그러나 데이터 전송에 대한 보장을 하지 않기 때문에 패킷(일종의 데이터 조각) 손실이 발생할 수 있다.
📌 Background : HTTPS
HTTP의 응답과 요청은 평문으로 전달된다. 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있다.
🚩 HTTPS
HTTPS(HTTP over Secure socket layer)는 TLS(Transport Layer Security) 프로토콜을 도입하여 이런 문제점을 보완한다. TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화한다. 공격자가 중간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능하며, 결과적으로 HTTP 통신이 도청과 변조로부터 보호된다.
HTTPS가 제정된 초기에는 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들 위주로 HTTPS가 사용되었으나, 현재 개발되는 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세이다.
