TCP/IP

네트워크가 발전하기 전의 초기 컴퓨터 시스템이 있었다. 초기 컴퓨터는 독립적으로 작동하며 다른 컴퓨터와 통신할 수 없었다. 기술의 발전으로 네트워크 개념이 등장했다.

네트워크 시작

1960년대, 미국의 고등 연구계획국(ARPA)이 네트워크 연구를 수행했다. 이는 ARPANET으로 알려진 최초의 컴퓨터 네트워크로 이어졌다. ARPANET은 1969년에 처음 구축되었다. 컴퓨터들이 패킷 스위칭 기술을 사용하여 통신할 수 있게 했다.

패킷 스위칭이 뭘까?

이전에 전기적 통신이 무엇이 있었을까? 바로 전화통화이다. 전화통화는 회선교환 방식이었다. 송신자와 수신자를 연결해줘야 했다. 회선 스위칭은 전송 경로를 설정한 후 전체 데이터를 연결된 경로를 통해 전송하는 방식이다.

회선교환 방식으로 네트워크 통신을 하다보니 문제가 있게 되었다. 회선교환 방식의 가장 큰 문제는 회선이 사용 중이면 다른 통신을 할 수 없다는 것이었다.

ARPANET에서는 패킷교환 방식으로 이 문제를 해결하려고 했다. 패킷이라는 단위로 데이터를 잘게 나누어 전송하는 방식이다. 인터넷 프로토콜이라는 기술을 이용하여 출발지와 목적지의 정보를 이용하여 패킷단위로 데이터를 전송했다.

IP/IP Packet

IP 패킷으로 인터넷망에 있는 노드(Node)들을 통해서 데이터를 전달한다. 노드는 네트워크의 기본 구성 요소이다. 노드는 컴퓨터, 라우터, 스위치, 서버, 게이트웨이 등과 같은 네트워크 장치를 말한다. 어떤 종류의 네트워크에 속해있는 장치라면 노드라고 말할 수 있다. 노드들은 서로 연결되어 인터넷망을 형성한다. 이 연결은 전화선, 광섬유 케이블, 무선 링크 등을 통해 이루어진다. 인터넷은 수많은 노드들이 연결되어 구성되어 있다.

즉, 노드는 인터넷망에서 데이터를 생성, 전송, 수신, 라우팅하는 등의 역할을 수행하는 네트워크 장치다.

• IP 주소 부여
  데이터가 출발지에서 목적지로 도착하기 위해서는 규칙이 필요할 것이다. 출발지와 목적지를 설정하는 것을 IP(Internet Protocol) 주소를 부여해서 통신을 할 수 있게 한다. IP라는 규칙은 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터를 전달하는 것이다.

• IP 패킷 정보
  Packet = pack + bucket
  IP 패킷에는 전송할 데이터 뿐만 아니라, 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP같은 정보가 포함되어 있다.

• 클라이언트 패킷 전달
  클라이언트에서 서버로 패킷 단위로 전송을 하면 노드(Node)들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다.

• 서버 패킷 전달
  서버에서 무사히 데이터를 전송받는다면 서버도 응답을 전송한다. 이 역시 IP 패킷을 이용해 클라이언트에 응답을 전달한다.

IP 한계

비연결성

패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 된다.

비신뢰성

중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없다.

전달 데이터의 용량이 클 경우 패킷 단위로 나눠서 전달하게 되는데 이 때 패킷들은 서로 다른 노드를 통해 전달될 수 있다. 이렇게 되면 의도하지 않은 순서로 전달 될 수 있다.

TCP/UDP

IP 패킷에는 비연결성, 비신뢰성 한계가 존재하기 때문에 보완이 필요했다. TCP Protocol이 IP Protocol을 보완한다.

네트워크 계층 모델

먼저 HTTP 메시지가 생성되면 Socket을 통해 전달된다. 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, "네트워크 환경에 연결할 수 있게 만들어진 연결부"가 바로 네트워크 소켓(Socket)이다

OSI 7계층 모델

TCP/IP 4계층 모델

HTTP

응용 계층의 대표적인 프로토콜인 HTTP

HTTP의 특징

클라이언트 서버 구조

클라이언트가 서버에 요청(Request)을 보내면 서버는 그에 대한 응답(Response)을 보내는 클라이언트 서버 구조로 이루어져 있다.
클라이언트는 서버에 요청을 보내고, 응답을 대기한다. 서버가 요청에 대한 결과를 만들어 응답한다.

무상태 프로토콜

서버가 클라이언트의 상태를 보존하지 않는다.

만약 서버가 클라이언트의 상태를 유지한다면?
서버가 여러대가 있다면 서버1에서 클라이언트의 상태를 유지한다고 하자. 클라이언트의 요청을 서버1에서 상태를 유지하기 때문에 서버1이 응답을 해줘야 한다. 서버1에서 에러가 난다면 상태 정보가 없어지기 때문에 처음부터 다시 서버에 요청해야 한다.

만약 서버가 무상태 프로토콜이라면?
클라이언트가 서버에 요청할 때 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 된다. 요청을 받은 서버가 에러가 나더라도 같은 기능을 하는 다른 서버가 응답을 하면 되기 때문에 다시 요청할 필요가 없다.

무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능하다.

무상태의 한계

로그인이 필요 없는 단순한 서비스 같은 경우에는 무상태를 설계할 수 있지만
로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다.

HTTP 메세지

단순함, 확장 가능

HTTP Headers의 종류와 특징

HTTPS

HTTP Secure

HTTP와 다른 점.
HTTPS는 HTTP와 달리 요청과 응답으로 오가는 내용을 암호화한다.
어떠한 방식으로 요청과 응답을 암호화할까?

암호화 방식

대칭 키 암호화 방식

암호화와 복호화할 때 쓰이는 키를 하나의 동일한 키만 사용한다.
두개 키를 사용하는 거에 비해 연산 속도가 빠르지만 키를 주고 받는 과정에서 탈취당했을 경우 암호화가 소용없어지기 때문에 키 관리에 신경써야 한다.

공개 키 (비대칭 키) 암호화 방식

암호화할 때 사용한 키와 다른 키로만 복호화가 가능하다.
두 개의 키를 각각 공개 키, 비밀 키라고 부른다. 공개 키는 이름 그대로 공개되어 있기 때문에 누구든지 접근 가능하다. 누구든 이 공개 키를 사용해서 암호화한 데이터를 보내면, 비밀 키를 가진 사람만 그 내용을 복호화할 수 있다.
보통 요청을 보내는 사용자가 공개 키를, 요청을 받는 서버가 비밀 키를 가진다.

공개 키를 사용해 암호화한 데이터가 탈취 당해도, 비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 더 좋다. 하지만 더 복잡한 연산이 필요해서 더 많은 시간을 소모한다.

SSL/TLS 프로토콜

HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 혹은 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행한다. 여기서 SSL이 표준화되며 바뀐 이름이 TLS이므로 사실상 같은 프로토콜이라고 생각하면 된다.

• CA를 통한 인증서 사용
• 대칭 키, 공객 키 암호화 방식을 모두 사용

인증서와 CA(Certificate Authority)

HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다. 이러한 인증서는 서버의 신원을 보증해준다. 이때 인증서를 발급해 주는 공인된 기관들을 Certificate Authority, CA라고 부른다.

서버는 인증서를 발급받기 위해 CA로 서버의 정보와 공개 키를 전달한다. CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급한다.

서버는 클라이언트에게 요청을 받으면 CA에게 발급한 인증서를 보내준다. 이때, 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있다. 우선 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고, 리스트에 있는 CA라면 해당하는 CA의 공개 키를 사용해서 인증서의 복호화를 시도한다.

CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로, 정말로 CA에서 발급한 인증서가 맞다면 복호화가 성공적으로 진행되어야 한다.

• 복호화가 성공적으로 진행된다면, 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 된다.
• 복호화가 실패한다면, 이는 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 알게 된다.

대칭 키 전달

서버의 인증서를 성공적으로 복호화하여 서버의 공개 키를 확보했다. 이 공개 키를 사용해서 데이터를 암호화하여 요청과 응답을 주고 받게 되지는 않는다. 공개 키 암호화 방식은 보안은 확실하지만, 복잡한 연산이 필요하여 더 많은 시간을 소모한다. 따라서 모든 요청에서 공개 키 암호화 방식을 사용하는 것은 비효율적이다.

이 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고받을 때 쓰게 된다. 대칭 키는 속도는 빠르지만 오고 가는 과정에서 탈취될 수 있다는 위험성이 있다. 하지만 클라이언트가 서버로 대칭 키를 보낼 때 서버의 공개 키를 사용해서 암호화하여 보내준다면, 서버의 비밀 키를 가지고 있는게 아닌 이상 해당 대칭 키를 복호화할 수 없으므로 탈취될 위험성이 줄어든다.

클라이언트는 데이터를 암호화하여 주고받을 때 사용할 대칭 키를 생성한다. 클라이언트는 생성한 대칭 키를 서버의 공개 키로 암호화하여 전달한다. 서버는 전달받은 데이터를 비밀 키로 복호화하여 대칭 키를 확보한다.

이제 HTTPS 요청을 주고 받을 때 이 대칭 키를 사용하여 데이터를 암호화하여 전달하게 된다. 대칭 키 자체는 오고 가지 않기 때문에 키가 유츌될 위험이 없다.
따라서 요청이 중간에 탈취되어도 제3자가 암호화된 데이터를 복호화할 수 없다.

이렇게 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정에서 데이터를 암호화하는 과정을 아우른 프로토콜 SSL 또는 TLS이라고 하고, HTTP에 SSl/TLS 프로토콜을 더한 것은 HTTPSf라고 한다.