NETWORK(DNS & 3/4 way Handshake & TLS/SSL & TCP/UDP)
인터넷 흐름(DNS 흐름)
인터넷에 www.tistory.com 이라는 주소를 입력을 하게 되면,
1) local DNS(기지국, SKT, KT, LG 서) 에게 www.tistory.com의 IP 주소를 묻는다. 이때 www.tistory.com을 들어갔던 적이 있다면, 캐싱되어 있던 정보가 있기때문에 IP정보를 주겠지만, 그렇지 않다면, 모른다고 답변을 하면서 Root DNS의 IP를 준다.
2) Root DNS에게 www.tistory.com의 IP 주소를 묻게되고, Root DNS 해당 주소의 IP 주소를 모르기 때문에 .com 도메인을 관리하는 DNS서버의 IP 주소를 알려주게 된다.
3) 이번엔 .com DNS에게 www.tistory.com의 IP 주소를 묻고, .com 도메인 DNS는 tistory.com 도메인을 관리하는 DNS 서버의 IP주소를 알려준다.
4) 마지막으로 tistory.com 도메일을 관리하는 DNS 서버(ns.tistory.com)에서 www.tistory.com의 IP 주소를 알려주고, 알려준 IP주소를 통해 웹서버에 접속이 가능해진다.(참고로 AWS의 Route53은 이 DNS서버에 해당한다)
5) IP를 받으면 HTTP 프로토콜을 활용하여 요청 메세지를 생성하고, TCP/IP프로토콜을 통해 전송한다.
웹 서버 또한 HTTP 프로토콜을 통해 요청메세지를 받고 응답 메세지를 생성한다.
6) 응답 메세지가 클라이언트에게 도착하면 메세지 내용이 브라우저에 출력된다.
* 이때, HTTP 사용시, TCP/IP 프로토콜로 연결 시에는 3way handshake(클라이언트 SYN, 서버 ACK+SYN, 클라이언트 ACK), 종료 시에는 4way handshake(클라이언트 FIN, 서버 ACK, 서버 FIN, 클라이언트 ACK)을 사용한다.
만약 HTTPS라면 연결 시 3 way handshake 다음에 보안을 위한 TLS/SSL handshake가 추가된다.
*TLS/SSL - SSL 은 데이터 암호화를 통해 네트워크 통신 보안을 제공하는 프로토콜이라면, TLS 는 SSL에서 더 발전한 형태로 인증서와 키 등을 통해 추가적인 개인 정보 보호 및 보안 기능을 지원한다.
TLS/SSL handshake
1) 클라이언트는 SSL 버전 정보와 암호화 알고리즘 종류를 서버에게 전달하고, 서버는 사용할 암호화 알고리즘을 정하고 공개키가 포함된 인증서를 클라이언트에제 전달한다.
2) 클라이언트는 인증서를 확인하여 공개키를 획득하고, 공개키로 대칭키를 암호화하여 서버에 전달한다.
3) 서버는 암호화된 대칭키를 개인키로 복호화하여 대칭키를 획득한다.
4) 대칭키를 활용하여 데이터를 주고 받는다.
이게 이해가 바로 쉽지는 않은데, 우선 자세히 봐보면
Client hello - SSL 버전과 가지고 있는 암호화 알고리즘 종류를 서버에 전달
Server Hello - 암호화 알고리즘을 선택(cipher suite)
Server Certificate Send - 공개키가 포함된 인증서를 클라이언트에 전달
Key Generation - 브라우저를 통해 인증서를 확인 후 대칭키를 생성.
client key exchange - 공개키로 대칭키를 암호화 해서 서버로 전달
server 행동 - 개인키(비공개키)를 통해 대칭키를 확인한다.
* 처음 대칭키는 pre master key라고 하며, 위 과정을 통해 양쪽 모두 pre master key를 가지게 되면, master key가 되고 이는 session key로 데이터 통신간에 key로서 사용된다. 그러다 통신이 끝나면 이 세션키는 파기 된다.
* 대칭키는 서버와 클라이언트가 같은 키를 가지고 데이터를 암호화 시키고 복호화 시키는 것이다. 제 3자가 대칭키를 획득한다면, 손쉽게 복호화 할 수 있다는 위험이 있다. 대신 대칭키는 속도가 빠르다는 장점이 있다.
* 공개키와 비공개키(개인키)에서 공개키는 말 그대로 공개된 키다. 공개키로 암호화 된 것은 공개키로 복호화 하는 것이 아니라 공개키를 만든 주체가 가지고 있는 비공개키(개인키)로 복호화 할 수 있다. 반대로 개인키로 암호화 된 것은 공개키로 복호화 해서 서명을 확인할 수 있다.(통신 간의 인증 몇 변조 검증을 할 수 있다.)
정리하면, 클라이언트와 서버는 둘 만의 암호를 정해서 통신하려고 한다. 근데, 그 둘만의 암호를 주고 받을 때, 남들이 알면 안된다. 서버는 물건을 넣을 수 있는 금고(돼지저금통처럼 바로 넣을 수는 있지만 뺄 수는 없는) 같은 것을 클라이언트에게 제공한다. 그래서 클라이언트가 이 금고에 암호를 넣을 수 있지만, 클라이언트를 포함해서 누구도 이 금고를 열 수 없다. 오직 서버만 이 금고를 열 수 있다.(금고를 여는 것이 개인키로 복호화) 그래서 클라이언트가 이 금고에 암호(대칭키)를 넣고 서버에 전달하면 암호(대칭키)는 서버만 확인할 수있게 되어 클라이언트와 서버가 둘 만의 암호로 위 과정을 다시 거치지 않고 빠르고 편리하게 통신이 가능한 것이다.
TCP와 UDP.
TCP는 에러 확인 및 복구를 위한 정보확인, 재전송하는 과정을 가진 통신 프로토콜이다. 그래서 연결시 3-way handshake, 연결 종료 시 4-way handshake를 수행한다. UDP는 이런 과정없이 그냥 데이터를 보낸다. 그래서 TCP는 UDP에 비해서 신뢰도는 높지만, 속도가 느리다. 그리고 UDP는 1: N가 가능하지만 TCP는 1:1 통신을 해야한다. 정보 손실이 일어나도 괜찮으며 빠른 속도가 필요할 때는 UDP를 사용하는 것이 좋고, 정보의 신뢰도가 중요하다면 TCP를 사용해야 한다.
