# 프로토콜, 인코딩
> 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계
다른 나라 사람들과 소통을 하기 위해서 언어가 필요하듯, 전자장치도 소통할 수 있는 언어가 필요합니다. 그 언어 역할을 하는 것이 프로토콜입니다.
OSI 7계층(응용, 표현, 세션, 전송, 네트워크, 데이터링크, 물리)마다 해당 계층에 사용되는 프로토콜이 있는데 해당 문서에서는 **응용 계층**에 사용되는 프로토콜을 설명합니다.
<br>
<br>
## 응용 계층
> OSI 모델의 최상위 계층으로, 다양하게 존재하는 응용 환경에서 공통적으로 필요한 기능을 다룹니다. 클라이언트 요청을 전달하기 위해 통신 대상(서버 등)이 이해할 수 있는 메시지(데이터)로 변환하고 전송 계층으로 전달하는 역할을 합니다.
응용 계층에 해당하는 대표적인 프로토콜로는 HTTP, FTP, DNS가 있습니다.
HTTP(HyperText Transfer Protocol)은 웹 서비스에서 클라이언트(웹 브라우저)와 웹 서버 간에 정보를 주고받기 위해 사용되는 프로토콜입니다.
FTP(File Transfer Protocol)은 서버와 클라이언트 간에 파일을 전송하기 위한 프로토콜입니다. 일반적으로 제어 용도로는 21번을, 데이터 전송 용도로는 20번 포트를 사용합니다.
DNS(Domain Name System)은 네트워크에서 호스트 이름을 IP 주소로 변환하는 데 사용하는 시스템(서비스)입니다. DNS 서비스가 동작하는 컴퓨터(서버)를 DNS 서버라고 하는데 보통 사용하는 통신사를 사용합니다.
<br>
<br>
## HTTP
> 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜.
클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메세지를 요청이라고 부르며, 서버에서 응답으로 전송되는 메시지를 응답이라고 부릅니다. 데이터 이동, 전달은 전부 텍스트를 기반으로 움직입니다.
1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. 이 HTTP가 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송되는 것을 HTTPS라고 합니다. HTTP의 확장성 덕분에, 텍스트 뿐만 아니라 이미지, 비디오, HTML 폼 결과와 같은 내용을 서버로 POST하기 위해
서도 사용됩니다.
<br>
<br>
## HTTP 흐름
1. TCP 연결을 엽니다. TCP 연결은 요청을 보내거나(혹은 여러 개의 요청)응답을 받는데 사용됩니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있습니다.
2. HTTP 메시지를 전송합니다. HTTP 메시지(HTTP/2 이전)는 인간이 읽을 수 있습니다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어 직접 읽는게 불가능하지만 원칙은 동일합니다.
3. 서버에 의해 전송된 응답을 읽어들입니다.
4. 연결을 닫거나 다른 요청들을 위해 재사용합니다.
<br>
<br>
## HTTP 쿠키
HTTP는 한 번 연결한 후에는 연결이 끊어지는(stateless) 특징을 갖고 있습니다. 그래서 서버 입장에서 두 요청이 동일한 브라우저에서 들어왔는지를 확인할 수가 없습니다. 이 때문에 나온 개념이 쿠키입니다.
HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 조각을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송하여 서버측에서 동일한 요청인지를 확인할 수 있게 됩니다.
쿠키를 이용한 일반적인 인증 프로세스는 다음과 같습니다.
1. 서버 헤더는 클라이언트에게 쿠키를 저장하라고 전달합니다.
```
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry
[page content]
```
2. 이제, 서버로 전송되는 모든 요청과 함께, 브라우저는 Cookie 헤더를 사용하여 서버로 이전에 저장했던 모든 쿠키들을 회신할 것입니다.
```
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
```
<br>
<br>
## HTTPS
> HTTP의 안전한 버전으로 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정하는 프로토콜
HTTP는 암호화되지 않은 데이터를 전송합니다. 즉, 브라우저에서 전송된 정보를 제3자가 가로채고 읽을 수 있습니다. 이 때문에 또 다른 보안 계층을 추가한 것이 HTTPS입니다. HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합합니다.
<br>
<br>
## HTTPS 프로토콜 작동방식
1. 사용자 브라우저 주소 표시줄에 https:// URL 형식을 입력하여 HTTPS 웹 사이트를 방문합니다.
2. 브라우저는 서버의 SSL 인증서를 요청하여 사이트의 신뢰성을 검증하려고 시도합니다.
3. 서버는 퍼블릭 키가 포함된 SSL 인증서를 회신으로 전송합니다.
4. 웹 사이트의 SSL 인증서는 서버 아이덴티티를 증명합니다. 브라우저에서 인증되면, 브라우저가 퍼블릭 키를 사용하여 비밀 세션 키가 포함된 메시지를 암호화하고 전송합니다.
5. 웹 서버는 개인 키를 사용하여 메시지를 해독하고 세션 키를 검색합니다. 그런 다음 세션 키를 암호화하고 브라우저에 승인 메세지를 전송합니다.
6. 이제 브라우저와 웹 서버 모두 동일한 세션 키를 사용하여 메시지를 안전하게 교환하도록 전환합니다.
<br>
<br>
## ASCII
컴퓨터는 문자나 기호, 숫자와 같은 것들을 읽지 못하고 이진수만 읽을 수 있습니다. 하지만 웹사이트에서는 여러 문자들이 쓰이는 것을 흔하게 볼 수 있는데 이는 실제로 저장이 되고 처리될 때는 이진수로 다뤄지기 때문입니다.
그렇다면 어떻게 특정 문자를 이진수로 변환하는 걸까요? 그것은 특정 표에 문자에 해당하는 이진수가 정의되어 있기 때문입니다. 그리고 이 표의 시초를 ASCII 코드라고 합니다.
아스키는 7비트 인코딩으로, 33개의 제어 문자들과 공백을 비롯한 95개의 문자들로 총 128개로 이루어집니다.
해당 표에서 알 수 있듯이 '0'이라는 문자는 십진법 48이되고 이는 이진법 0110000으로 컴퓨터에 저장됩니다. 그런데 7비트의 공간으로는 다양한 나라의 언어를 수용할 수 없었기에 저장공간을 늘리고 다른 나라의 글자를 넣어서 만들어진 다양한 표가 생겨납니다. 우리가 흔히 알고있는 EUC-KR과 UTF-8이 ASCII를 확장한 표인 것입니다.
<br>
<br>
## UTF-8, UTF-16, EUC-KR
UTF-8과 UTF-16은 문자를 저장할 때 필요한 비트 수가 다릅니다. UTF-8은 1-4Byte를 사용하고 UTF-8은 2Byte를 사용합니다. 한글을 저장하는 경우에는 UTF-8의 경우 3Byte를 사용하고 UTF-16은 2-4Byte를 사용합니다. UTF-8은 가장 많이 쓰이는 인코딩이지만 자바의 경우에는 UTF-16을 사용합니다.
EUC-KR은 한국에서 독자적으로 사용하고 있는 인코딩 방식으로 초성, 중성, 종성을 조합하여 인코딩하는 것이 아닌 완성된 상태의 문자를 2Byte로 표현하는 방식입니다.
그리고 이 EUC-KR이 발전된 것이 CP949인데요, 이 CP949는 윈도우에서 기본적으로 사용하고 있는 인코딩입니다.
결론적으로는 저장되는 문서의 인코딩과 처리하는 곳의 인코딩을 동일하게 맞추는 것이 중요합니다.
<br>
<br>
## VARCHAR, NVARCHAR
VARCHAR(N)에서 N은 바이트로 1-8000사이의 값을 가질 수 있습니다. UTF-16인코딩 방식의 VARCHAR에서는 영어는 1Byte를 한글은 2Byte를 차지하게 됩니다.
NVARCHAR(N)에서 N은 바이트 쌍으로, 1-4000사이의 값을 가질 수 있습니다. UTF-16인코딩 방식의 NVARCHAR에서는 영어와 한글 모두 2Byte를 사용합니다. 하지만 유니코드 범위가 (0-65,535)의 경우에서만 바이트 쌍당 하나의 문자를 저장할 수 있고 (65,536-1,114,111)에서는 한 문자가 두 개의 바이트 쌍을 공유할 수도 있습니다.
즉, 한글은 AC00(44032)-D7AF(55247)에 속하기 때문에 2바이트를 사용하지만 65,536이상의 데이터는 4Byte를 사용하게 됩니다.
MSSQL 15.0버전으로 예시를 들어보겠습니다.
```mssql
DECLARE @NAME NVARCHAR(3) = '가나다';
DECLARE @NAME2 VARCHAR(3) = '가나다';
SELECT @NAME, @NAME2;
```
NVARCHAR(N)은 N바이트 쌍을 가지므로 NVARCHAR(3)은 6바이트 스토리지를 가집니다. '가나다'는 UTF-16에서는 2Byte * 3 = 6Byte를 가지기 때문에 짤리지 않지만 VARCHAR(N)은 N바이트를 가지기 때문에 글자가 잘리게 됩니다.
즉, 어떤 프로그램이 어떤 인코딩방식을 사용하는지 파악하고 현재 설계하는 테이블에서 어떤 글자를 주로 사용하는지에 따라서 데이터 타입을 설계해야 합니다.
a
Google Drive
Gist
Clipboard
Sign in with Wallet
