ex) A라는 데이터를 보낸다면, A-1, A-2, ..., A-10 이런식으로 잘게 나누어 데이터를 전송한다. 잘게 나누어진 것들이 패킷!
데이터를 패킷으로 나누는 기준이 MTU(Maximum Trasmission Unit) MTU란 패킷의 최대 크기를 나타내는 수치.
-. MTU값이 작으면 패킷수가 많아진다
=> 패킷이 가지고 있는 공통 header들을 처리하는 양이 늘어나므로 overhead가 늘어나는 문제 발생. -. MTU값이 크면 패킷수가 줄어들기 때문에 한번에 많은 데이터를 보낼수 있으므로 대량의 데이터를 처리할 때 이점이 있다.
=> 하지만 패킷이 훼손되어 오는 경우에는 다시 큰 패킷을 요청해야하는데, 패킷이 큰 만큼 오는데 오랜 시간이 걸리게 된다.
패킷은 하나의 루트로만 전송되지 않는다. 여러 루트를 통해서 전송이 가능한데 여러 루트마다 도착시간이 달라서 순서가 보장되지 않는다. 데이터를 받는쪽은 A-2,A-10,…, A-1 데이터를 순서에 맞게 A-1,A-2,…,A-10으로 재조립 한다. 순서에맞게 재조립이 가능한 이유는, TCP 방식으로 데이터 전송시 Header가 붙게되는데 Header에 순서에 관한 정보(Sequence Number)가 있기 때문이다.
[참고] TCP 헤더
TCP헤더 구조를 보면 Source Port는 송신측의 port 번호를 나타낸다. Destination Port는 수신측의 port번호를 나타낸다. CheckSum은 패킷의 훼손여부를 체크하는 역할을 한다. SYN은 통신을 하는 양측의 SequenceNumber를 동기화 하기위해 사용된다. ACK는 데이터를 잘 받았다는 응답을 전달하기 위해 사용되며 Sequence Number에 + 1을 붙이는 방법을 이용한다.
Text Transfer라는 단어가 들어간걸 봐서는 둘이서 문자를 서로 주고 받는 것인데, Hyper가 들어가서 인지 글을 주고 받았지만 엄청난 일들이 이루어진다. HTTP 방식이 없었다면 지금 이렇게 글을 쓰고 조회 할 수 있는 이런 일들이 가능했을까?
클라이언트(Client)는 HTTP를 통해 데이터를 서버로요청(Request)하는 요청자이며, 흔히 크롬, IE, FireFox 같은 웹 브라우저가 그 역할을 한다. 응용 프로그램에서는 Http 요청을 위해 사용하는 라이브러리가 그 역할을 한다.
서버(Server)는 클라이언트가요청한 데이터를 제공하는 제공자이며 이미지, HTML 파일처럼 파일을 제공하는 서버, 요청 주소에따라 다른 내용을 제공하는 API서버 등 다양하게 있다. HTTP 통신에서는 서버가 제공하는 결과를응답(Response)이라고 한다.
HTTP 메시지 구조
요청 메시지와 응답 메시지 구조 첫 줄을빼고는 구조가 똑같다.
HTTP통신을 위해 생성되는 메시지를 뜯어보면 크게Header와Body로 나눌수 있다.
Header는 General Header, Request header, Response Header, Entity header로 나뉜다.
General Header : 요청과 응답에서 모두 공통으로 들어가는 Header를 의미한다. 주요 정보들로 Date (HTTP 메시지 생성 시간), Connection (서버와 클라이언트의 연결옵션), Via(메시지가 어느 중개자를 거쳐서 왔는지), Transfer-Encoding (메시지에 적용된 인코딩 값) 등등이 있다.
Request Header : 요청시에만 있는 Header이다. 주요 정보들로 Host(서버의 호스트명과 포트), User-Agent (브라우저 및 기기 버전 등 요청자에 관한 정보), Referer(요청을 보낸 URL), Accept(클라이언트가 받을 수 있는 미디어 타입), Accept-Encoding(클라이언트가 받을 수 있는 인코딩), Authorization(서버 인증을 위한 정보) 등등이 있다.
Response Header : 응답시에만 있는 Header이다. 주요 정보들로 Server(서버 어플리케이션 이름과 버전), Age(응답이 캐쉬된 시점부터 얼마나 오래 되었는지), Set-Cookie(서버에서 클라이언트에게 설정한 쿠키정보), Allow(서버측에 요청가능한 HTTP 요청방식) 등등이 있다.
Entity Header: HTTP메시지의 BODY(본문)에 관한 정보가 있는 Header. 주요 정보들로 Content-Encoding(본문에 적용된 인코딩), Content-Length(본문의 크기), Content-Type(본문의 응답이 어떤 타입인지), Content-Location(본문이 실제존재하는 위치), Expires(본문이 캐시되어 유효한 시간), Last-Modified(본문이 마지막으로 갱신된 시간), ETag(본문의 고유 태그, 본문이 수정되면 태그 갱신됨) 등등이 있다.
Body는 요청시 전달하는 데이터 내용, 응답시 받는 데이터 내용으로 HTTP 문서 마지막에 들어간다. Body는 요청과 응답에 따라 있을수도 없을수도 있으며 Body가 없으면 Entity Header도 없다.
HTTPS
HTTP 통신은 앞서 말한것 처럼 HTTP 메시지(텍스트)를 주고 받으며 통신을 한다. 이 메시지에는 보안 장치가 따로 없다. 누군가 악의적인 목적으로 HTTP 메시지를 통신 중간에 가로채서 HTTP 메시지를 볼 수도 있다.HTTP 메시지는 암호화없이 평문으로 전송되기 때문에 통신을 가로채면 보낸 내용을 쉽게 볼 수 있다.
만약 회원가입을 하는 경우에 이런 일이 발생하면 개인정보는 바로 노출되게 된다. 이를 보완하기위해 나온것이 HTTPS(HyperTextTransferProtocol overSecure Socket Layer)이다. 약자를 보면 Secure라는 단어가 들어가는데, HTTP의 보안적인 단점을 커버한 HTTP 프로토콜의 강화버전이다.
결론만 간단하게 말하면 HTTP 메시지가 암호화 되어 통신을 하게 된다.
HTTPS통신과정
HTTPS 통신과정을 알기 위해서는 대칭 키,공개 키의 개념을 알아야 한다.
대칭 키(Symmetric Key)는 정보를 암호화하고 복호화를 할때 같은 값을 이용하는 경우에 사용되는 키이다.
예를들어 ABCD라는 문자를 1111이라는 값으로 암호화를 하고 암호화된 문자를 1111이라는 값으로 풀어서 ABCD를 볼 수 있다면 1111이 대칭 키가 되는 것이다.
대칭 키는 암호화, 복호화가 간단한 방법이다. 하지만 대칭 키를 다른 사람이 알게 되면 그 사람도 암호화된 문자를 생성하고 풀 수 있기 때문에 대칭 키가 노출되는 경우에는 보안에 부정적인 영향이 발생 할 수 있다.
공개 키(Public Key) 방식은 암호화에 사용하는 키와 복호화에 사용되는 키를 분리하는 것이다.
암호화를 할때는 공개 키를 이용해 암호화를 하고 복호화를 할 때는비밀 키(private key)를 이용한다. 이렇게 되면 공개 키가 노출 되더라도 복호화를 위해 필요한 비밀 키를 모르면 복호화를 할 수가 없다.
공개 키 방식은 대칭 키 방식의 보안 문제를 해결한 방법이지만 컴퓨터 자원이 더 많이 들어가는 단점이 있다.
추가로SSL인증서는 클라이언트가 접속한 서버가 신뢰할수 있는 서버라는걸 입증해 주는 역할을 하고, SSL 통신에 필요한 공개키를 클라이언트에게 제공한다.(서비스 정보 & 공개 키에 관한 내용이 있음.)
CA(Certificate Authority)는 SSL인증서를 보증해주는 외부 기관들이다.
HTTPS 통신 과정을 간단히(??) 정리해보면.
서버는 CA기관으로 사이트 정보와 공개 키를 전달함.
CA기관에서 해당 사이트를 검증하고 나서 사이트 정보와 공개 키를 인증기관의 개인 키로 암호화 하여 SSL 인증서를 제작함.
해당 사이트에 SSL인증서를 발급 함.
CA 기관은 브라우저에게 CA기관의 공개 키를 제공함.
클라이언트가 서버로 접속시, 서버로 random 값과 클라이언트 측에서 사용가능한 암호화 기법을 서버로 전송. (Client Hello)
서버에서 random 값과 서버에서 처리가능한 암호화(동일한 암호화 알고리즘을 사용하기 위해 협상 하는 단계) 기법과 SSL인증서를을 함께 클라이언트에게 전송. (Server Hello)
브라우저에 내장된 CA 리스트 정보로 부터 CA가 제공한 공개 키를 이용해 SSL인증서를 복호화 함. 복호화가 성공한다면 인증된 서버임이 확인되고, 공개 키를 클라이언트가 얻게 됨. 서버는 비밀 키를 가지고 있음.
클라이언트는 클라이언트 측 random 값과 서버로 부터 받은 random 값을이용해서 대칭 키 생성함. 이 대칭 키는 실제 데이터를 주고 받을때 사용됨.
클라이언트는 SSL인증서 안에있는 공개 키를 이용해 생성한 대칭 키를 암호화 시켜 서버로 전송함. 이때 전송된 내용은 암호화 됨.
서버는 대칭 키를 비밀 키를 이용해 복호화함. 이제 클라이언트와 서버 모두 대칭 키를 가지고 있음.(5~10번까지의 과정을 handshake라고 함.)
이후 부터는 클라이언트와 서버는 대칭 키를 이용해 데이터를 암호화, 복호화를 하며 요청과 응답을 처리함.
