들어가며
언어에서 약속이란, 문장의 의미를 결정하는 매우 중요한 요소
⇒ 컴퓨터에서도 마찬가지
인코딩
인코딩(Encoding) 표준: 0과 1로 우리의 문자를 표현하도록 약속한 것
인코딩 표준에는 대표적으로 아스키와, 유니코드가 있음.
- 아스키(Ascii) ⇒ 7비트 데이터에 대한 인코딩 표준. 알파벳과 특수 문자 등을 표현할 수 있음 ⇒ 컴퓨터가 개발된 초기에는 각 문자권마다 고유의 인코딩 표준을 사용함. (영어는 아스키, 한글은 CP-949, EUC-KR 등을 사용) ⇒ 국제 소프트웨어 개발시 인코딩이 호환되지 않아 글자가 깨지는 것과 같은 오류가 발생함
- 유니코드(Unicode) ⇒ 아스키코드의 어려움을 해결하고자 만들어진 표준 ⇒ Uni(하나의)라는 접두사가 나타내듯 모든 언어의 문자를 하나의 표준에 담겠다는 목표로 제정 ⇒ 한 문자를 최대 32개의 비트로 표현함. 즉, 표현할 수 있는 정보의 가짓수가 2^32,42억개로 전세계 문자를 표현하고도 남을 넓은 공간.
인코딩을 이용하면 우리의 문장을 컴퓨터에 저장하고, 표현할 수 있습니다. 그리고 네트워크를 이용하면 인코딩한 정보를 다른 사람들과 쉽게 교환할 수도 있습니다.
통신 프로토콜
웹 서버에 있는 리소스를 클라이언트가 받아보려면, 클라이언트는 웹에게 특정 리소스를 지정하여 제공해달라고 요청해야함. 그러면 서버가 해당 요청을 이해하고 , 대응되는 동작을 통해 클라이언트에게 리소스를 반환한다.
Request(요청) : 클라이언트의 행위
Response(응답) : 서버의 행위
프로토콜(Protocol) : 규격화된 상호작용에 적용되는 약속
컴퓨터가 해석의 융통성을 발휘하는 것은 어렵고, 통신 오류가 발생할 가능성을 높이기에 엄격한 프로토콜을 사용해야한다.
많은 프로토콜은 각 통신 주체가 교환하는 데이터를 명확히 해석할 수 있도록 **문법(syntax)**를 포함함
⇒ 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시함.
현재까지 제정된 표준 통신 프로토콜의 예는 아래와 같다.
- TCP/IP : 네트워크 통신
- HTTP : 웹 애플리케이션이 사용
- FTP : 파일을 주고받을 때 사용
HTTP
HTTP(Hyper Text Transfer Protocol)
: 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜
기본 메커니즘
클라이언트가 서버에게 요청하면,
서버가 응답하는 것
웹서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킴
⇒ 포트는 일반적으로 TCP/80 또는 TCP/8080임.
⇒ 클라이언트가 서비스포트에 HTTP 요청을 전송하면, 이를 해석하여 적절한 응답을 반환함
네트워크 포트 : 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소
⇒ 항구 의미로 생각하니 이해 잘 됨. 클라이언트가 서버의 포트에 접근하는 것 생각하기
서비스 포트 : 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트
HTTP가 80번 포트를 점유하고 있다면, HTTP의 서비스 포트는 80번 포트가 된다.
⇒ 두개가 다른게 아님. 네트워크 포트에서 서비스가 차지하는 포트를 서비스 포트라 함
포트로 데이터를 교환하는 방식은 **전송계층(Transport Layer)**의 프로토콜을 따름
⇒ TCP, UDP가 있다
⇒ TCP로 데이터를 전송하려는 서비스에 UDP클라이언트가 접근하면 데이터가 교환되지 않기에 서비스 포트를 표기시 사용하는 전송계층 프로토콜을 같이 표기하기도 한다.
⇒ HTTP 서비스 포트가 TCP/80이다 == HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다
잘 알려진 포트(Well-known port),특권포트(Privileged port) : 0번 ~ 1023번 포트
⇒ 각 포트에 유명한 서비스가 등록됨. 해당 포트에 서비스 실행하려면 관리자 권한 필요
- SSH : 22번포트
- HTTP : 80
- HTTPS: 443
HTTP 메시지
아래의 2가지 경우가 존재함
- 클라이언트가 전송하는 HTTP 요청
- 서버가 반환하는 HTTP 응답
둘 다 HTTP 헤더와 바디로 구성됨
HTTP 헤더
HTTP 헤드(Headers) 각 줄은 CRLF로 구분
첫 줄은 시작 줄(Start line)
⇒ 요청과 응답에서 차이 존재
나머지 줄은 헤더(Header)
⇒ 필드와 값으로 구성됨. (필드명 : 필드 값)
HTTP 메시지 또는 바디의 속성을 나타냄.
하나의 HTTP 메시지에는 0개 이상의 헤더가 있을 수 있음
헤드(Headers)의 끝은 빈줄로 나타냄
HTTP 바디
HTTP 바디(Body) : 헤드의 끝을 나타내는 CRLF 뒤 모든 줄
클라이언트나 서버에게 전송하려는 데이터가 바디에 담김
HTTP 요청
HTTP 요청 : 서버에게 특정 동작을 요구하는 메시지
시작줄
메소드(Method), 요청 대상(Request target), 그리고 HTTP 버전으로 구성
⇒ 각각은 띄어쓰기로 구분
메소드 : 요청대상에 대해 서버가 수행하길 바라는 동작을 나타냄
⇒ HTTP 표준에서는 8개의 메소드를 정의하고 있음
- GET : 리소스를 가져와 달라 요청하는 메소드
- POST : 요청 대상에게 데이터를 보내는 메소드 ⇒ 전송할 데이터는 보통 HTTP 바디에 포함됨
HTTP 요청 메서드 - HTTP | MDN
HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. 간혹 요청 메서드를 "HTTP 동사"라고 부르기도 합니다. 각각의 메서드는 서로 다른 의미를 구현하지만, 일부
developer.mozilla.org
요청 URI(=요청대상) : 메소드의 대상을 나타냄
HTTP 버전 : 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타냄
HTTP 응답
HTTP 응답 : HTTP 요청에 대한 결과를 반환하는 메시지
HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 처리 사유(Reason Phrase)로 구성
HTTP 버전: 서버에서 사용하는 HTTP 프로토콜의 버전을 나타냄
상태코드 : 요청에 대한 처리결과를 세 자릿수로 나타냄
⇒ 각각 첫번째 자리스에 따라 5개의 클래스로 분류됨
처리사유 : 상태코드가 발생한 이유를 짧게 기술한 것
HTTPS
HTTP의 응답과 요청은 평문으로 전달됨
만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있음.
⇒ 예를 들어, 로그인할 때 전송한 POST 요청에는 대개 이용자의 ID와 비밀번호가 포함됨.
공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있음
HTTP 통신. 빨간글자가 요청, 파란글자가 응답. wireshark 이용
HTTPS(HTTP over Secure socket layer) : TLS(Transport Layer Security) 프로토콜을 도입함.
TLS : 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화함
⇒ 공격자가 중간에 메시지를 탈취하더라도, 복호화할 수 있는 키가 없다면 해석할 수 없음
웹 서버의 URL이
http://로 시작되면 HTTP,
https://로 시작되면 HTTPS 프로토콜을 사용
키워드
- HTTP(HyperText Transfer Protocol): 웹 서버와 클라이언트가 리소스를 교환하기 위해 사용하는 프로토콜. 클라이언트가 요청하면, 서버가 응답하는 방식.
- HTTP 메시지: HTTP 서버와 클라이언트가 교환하는 데이터. 헤드와 바디로 구성되며, 각 줄은 CRLF로 구분됨.
- 헤드: 메시지에 대한 정보. 헤드의 끝에는 CRLF가 한 줄 있음.
- 바디: 클라이언트가 서버에게, 또는 서버가 클라이언트에게 전달할 데이터
- HTTP 요청(Request): 클라이언트가 서버에게 특정 동작을 요청하는 메시지
- 메소드(Method): 요청 URI가 가리키는 리소스에 대해, 서버가 수행했으면 하는 동작을 지정
- 요청 URI(Request-URI): 메소드의 대상이 되는 리소스를 지정
- HTTP 응답(Response): 요청을 처리한 결과 및 이유, 그리고 클라이언트에 전송할 웹 리소스를 포함하는 메시지
- 상태 코드(Status code): 요청을 처리한 결과
- 처리 사유(Reason phrase): 상태 코드가 발생한 이유
- HTTPS(HTTP on Secure socket layer): TLS를 이용하여 HTTP의 약점을 보완한 프로토콜
