알고리즘 고수가 되기까지

설명 순서는 다음과 같습니다.

1. OSI 7계층이란?
2. OSI 7계층을 나눈 이유
3. OSI 7계층 구조

1. OSI 7계층이란?

   - OSI 7계층은 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말함

2. OSI 7계층을 나눈 이유

   - 통신이 일어나는 과정을 단계별로 나눠서 모듈화 함으로써, 이해하기 쉽고 7계층 중에 특정한 곳에 문제가 발생했을 때 다른 계층의 장비를 건드리지 않고 해결할 수 있기 때문

3. OSI 7계층 구조

   - 1계층(물리계층) : 비트로 이루어진 데이터를 전달하는 계층. 단지 데이터를 전달만 할 뿐임

   - 2계층(데이터링크 계층) : 물리계층으로 송수신되는 정보를 관리해서 안전하게 전달되도록 도와주는 계층. 에러검출, 재전송, 흐름제어를 진행함

   - 3계층(네트워크 계층) : 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 하는 계층. 라우터를 통해 이동할 경로를 선택하고 해당 경로에 따라 패킷을 전달함

   - 4계층(트랜스포트 계층) : 데이터를 어떻게 전달할지 정하는 계층. 대표적으로 TCP, UDP가 있는데 TCP는 데이터의 신뢰성을 보장하는 프로토콜이고 UDP는 신뢰성을 보장하지 않음

   - 5계층(셰션 계층) : 데이터가 통신하기 위한 논리적인 연결을 담당하는 계층. TCP/IP 세션을 만들고 없애는 책임을 함

   - 6계층(프레젠테이션 계층) : 데이터의 포맷을 관리하는 계층. 인코딩 or 디코딩, 암호화 or 복호화 등을 담당하는 계층

   - 7계층(애플리케이션 계층) : 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는 단계

OSI 7계층에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 입력한 URL의 IP 주소 찾기
2. 브라우저와 서버와 TCP 연결
3. 브라우저가 서버에 요청을 보냄
4. 서버는 요청을 받고 처리한 후 클라이언트에 응답을 보냄
5. 브라우저는 받은 응답을 렌더링해서 표시함

1. 입력한 URL의 IP 주소 찾기

   - 브라우저에 입력한 URL은 실제 주소의 별명임. 그러므로, 실제 주소인 IP를 알아야함

   - DNS는 별명과 IP주소를 <키, 값> 형태의 맵으로 갖고 있음. 따라서, DNS에 URL의 실제 IP 주소를 요청해서 알 수 있음

   - 바로 DNS에 IP주소를 묻기 전에 브라우저는 먼저 네 개의 캐시를 확인함

      ① 브라우저 캐시를 확인한다. 이전에 방문했던 웹 사이트의 DNS 기록을 일정기간 동안 저장하고 있음

      ② OS 캐시를 확인한다. OS의 시스템 호출로 DNS 기록을 가져옴

      ③ 라우터 캐시를 확인함

      ④ ISP 캐시를 확인함. ISP란 Internet Service Provider인데 이는 DNS 서버를 갖고 있어서 해당 서버에서 DNS 기록 캐시를 확인함

   - 캐시에서 찾을 수 없다면 IP 주소를 찾기 위해 DNS 서버에 요청을 함

   - DNS 서버에서 재귀적 질의를 통해 IP 주소를 획득

2. 브라우저와 서버와 TCP 연결

   - HTTP 프로토콜은 일반적으로 TCP 프로토콜을 사용함

   - TCP연결은 3 way handshake 과정을 통해 연결됨

   - 3 way handshake는 데이터의 신뢰성을 보장하기 위해함

3. 브라우저가 서버에 요청을 보냄

4. 서버는 요청을 받고 처리한 후 클라이언트에 응답을 보냄

5. 브라우저는 받은 응답을 렌더링해서 표시함

브라우저에 URL을 입력하면 발생하는 일에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 트랜스포트 계층
2. TCP란
3. UDP란

1. 트랜스포트 계층

   - 트랜스포트 계층은 송신자와 수신자 간 데이터의 전달을 담당하는 계층

   - 이 계층에서 사용되는 대표적인 프로토콜이 TCP와 UDP임

   - 이 둘은 '어떻게 데이터를 전달할 것인가?' 가 다른 프로토콜임

2. TCP란

   - TCP는 초점을 '신뢰성' 에 둔 데이터 전송방식 임

   - 여기서 '신뢰성'이란 송신자가 보낸 데이터가 수신자에게 그대로 전달됨은 보장함을 뜻함

   - 그래서 데이터를 보내기 전에 미리 3 way handshake를 맺고, 패킷에 번호를 붙여 순서와 유실성을 판단하고, 데이터를 다 보낸 후에는 4 way handshake를 통해 연결을 종료함

   - 데이터의 신뢰성이 중요한 서비스에서 사용됨

3. UDP란

   - UDP는 초점을 '속도' 에 둔 데이터 전송방식 임

   - 여기서 '속도'란 송신자가 보낸 데이터가 빠르게 수신자에게 전달하는 것이 목적임을 뜻함

   - 단순히 보낼 패킷을 수신자에게 보낼 뿐이어서, 중간에 유실될 수도 있고 패킷의 순서 또한 보장할 수 없음

   - 신뢰성보다 속도가 중요한 서비스에서 사용됨(ex. 스트리밍)

TCP와 UDP에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. 쿠키, 세션의 등장 배경
2. 쿠키의 동작 방식
3. 세션의 동작 방식

1. 쿠키, 세션의 등장 배경

   - 웹을 이용할 때 사용하는 프로토콜인 HTTP는 stateless임.

   - 이 뜻은 서버로 가는 모든 요청이 독립적이라서 이전에 보낸 요청과 연관성이 없다는 뜻임.

   - 그래서 만약 A가 어떤 웹사이트에 로그인을 했다면, A는 그 서버에 '나는 로그인한 사용자 A'라는 정보를 보내줘야함.

   - 이렇게 stateless한 HTTP 프로토콜에 state를 유지할 수 있게 도와주는 역할이 쿠키와 세션임 

2. 쿠키의 동작 방식

   - 동작 방식(ex. 아이디 기억)

      ① 브라우저는 아이디와 비밀번호를 입력하고, 'id 저장'이라는 체크박스를 체크 후 서버에 전송

      ② 서버는 'id 저장'이 true인 것을 확인하고, [ "rememberId" : "i123d" ] 라는 쿠키를 만들어서 브라우저에 전송

      ③ 해당 쿠키는 브라우저에 저장되고, 이 쿠키는 해당 서버에 요청할 때 자동으로 보내지게 됨

      ④ 로그인 입력창에 갔을 때, 서버는 해당 요청에 key가 "rememberId"인 쿠키가 있는 것을 확인하고, 그 value인 "i123d"를 아이디 창에 보여줌

   - 위와 같은 방식으로 이전에 했던 요청과 현재 요청을 연결함

3. 세션의 동작 방식

   - 세션은 쿠키와 함께 동작함

   - 동작 방식(ex. 로그인)

      ① 브라우저는 아이디와 비밀번호를 서버에 전송

      ② 서버는 아이디와 비밀번호가 일치하면, 해당 유저의 정보를 세션 저장소(메모리, DB...)에 저장하고 그 공간을 가리키는 unique한 id를 쿠키로 만들어서 브라우저에 전송

      ③ 브라우저는 이 후 다른 웹페이지를 요청하더라도 해당 쿠키를 같이 전송

      ④ 서버는 쿠키값을 이용해서 세션 저장소를 확인하고, 해당 요청이 로그인된 사용자라는 것을 인지

   - 위와 같은 방식으로 이전에 했던 요청과 현재 요청을 연결

   - 여기서 쿠키는 단지 세션의 unique한 id를 전달하는 것이고, 중요한 user의 정보는 모두 세션(서버쪽)에 저장됨

   - 하지만, 세션/쿠키 방식은 서버에 많은 사람의 정보를 갖고있어야한다는 점에서 서버에 부하가 올 수 있음

   - 이런 세션/쿠키 방식을 보완하기 위해 token방식이 등장(-> 다음에 조사해봐도 좋을듯)

쿠키와 세션에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다

1. 트랜스포트 계층의 역할
2. TCP란
3. 3 way handshake & 4 way handshake

1. 트랜스포트 계층의 역할

   - 트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 애프리케이션 프로세스를 논리적으로 연결하는 역할을 담당함

   - 서로 다른 프로세스 간 데이터를 전달하고 받는 프로토콜

   - 주 목적

      ① 내 프로세스에서 받은 데이터를 다른 프로세스에게 전달

      ② 다른 프로세스에서 받은 데이터를 내 프로세스에게 전달

   - '전달'이 핵심

2. TCP란

   - 인터넷 애플리케이션 계층에게 주어지는 트랜스포트 계층 프로토콜 중 하나

   - TCP 프로토콜의 특징은 '데이터의 신뢰성'을 보장한다는 것임

   - '데이터의 신뢰성'이란 보낸 데이터가 그대로 수신자에게 전달됨을 보장한다는 뜻임

   - 만약 A와 B가 메시지를 주고 받는다고 가정하면 고려해야할 사항은 다음과 같음

      ① 메시지를 보내기 전 'B가 살아있을까? B가 맞을까?'를 확인(B 또한 A를 확인)

         : B가 받지 못하는 상황이거나 엉뚱한 사람에게 보내면 안되므로, 이를 확인하는 과정이 필요 -> 3 way handshake

      ② 보낸 메시지가 순서대로 잘 전달되었을까?

         : 패킷 단위로 전달이 되는데, 이 때 받는 순서는 바뀔 수 있음. 하지만, 보내는 사람이 패킷에 번호를 붙이고 받는 사람은 이 번호를 이용하여 다시 순서대로 재조립할 수 있게해야 함

      ③ 보낸 메시지가 모두 다 전달되었을까?

         : 보낸 패킷이 모두 전달되어야함. 따라서, 받는 사람은 패킷을 받을 때 마다 받았다는 응답을 주면 보낸 사람은 받았다는 응답 갯수로 패킷이 모두 전달되었는지 알 수 있음

3. 3 way handshake & 4 way handshake

   - 3 way handshake는 데이터를 주고받기 전, 두 엔드포인트간 서로를 확인하는 과정임

   - 진행되는 순서는 다음과 같음

      ① A는 B에게 '내가 너한테 데이터를 전달해도 되지?' 라는 메시지를 보냄 -> SYN

      ② B는 A에게 '응, 나도 너한테 데이터를 전달해도 되지?' 라는 메시지를 보냄 -> ACK + SYN

      ③ A는 B에게 '응' 이라는 메시지를 보냄 -> ACK

   - 이렇게 총 3단계를 거쳐서 데이터를 주고받기 전에 미리 '연결'을 시켜놓음 -> TCP의 연결지향형 특징

   - 4 way handshake는 연결을 끊을 때 하는 과정임

   - 진행되는 순서는 다음과 같음

      ① A가 B에게 '데이터를 다 보냈으니 연결을 끊을게' 라는 메시지를 보냄 -> FIN

      ② B는 A에게 '응' 이라는 메시지를 보냄 -> ACK

      ③ B또한 데이터를 다 보냈을 경우 A에게 '나도 연결을 끊을게' 라는 메시지를 보냄 -> FIN

      ④ A는 '응' 이라는 메시지를 보냄 -> ACK

      ⑤ 종료

   - 서로 주고받은 데이터가 완료되었음을 확인하고 안정적으로 연결을 종료

3 way handshake와 4 way handshake에 대해 알아볼 수 있었습니다.

설명 순서는 다음과 같습니다.

1. HTTP란?
2. HTTPS가 등장하게 된 배경
3. 두 가지 암호화 방식, 대칭키와 비대칭키
4. HTTPS를 이용한 전체적은 요청-응답 흐름

1. HTTP란?

   - HTTP란 Hyper Text Transfer Protocol의 약자입니다

   - 이 뜻은 Hyper Text를 전달하는데 사용되는 Protocol이란 뜻입니다

   - Hyper Text란 단순한 텍스트를 넘어 링크로 다른 문서로 넘어갈 수 있는 텍스트와 여러 멀티미디어 요소로 이루어진 문서를 말합니다

   - 이러한 Hyper Text는 HTML이라는 마크업 언어로 작성됩니다

   - Protocol은 약속을 의미합니다

   - 둘 사이에 메시지나 데이터를 주고받을 때 정해진 형식입니다

   - 따라서, HTTP는 HyperText를 요청하고 전달받는데 정해진 규칙을 의미합니다

   - 요즘 HTTP는 단순히 HyperText를 넘어 이미지, JSON 등 다양한 데이터를 주고받을 때 사용합니다

2. HTTPS의 등장배경

   - 우리는 네트워크 위에서 HTTP 규약에 맞는 요청 및 응답메시지를 주고받을 수 있게 되었습니다

   - 하지만, HTTP는 암호화를 하지 않고 평문으로 전송하기 떄문에, 네트워크 상에서 데이터를 탈취당할 수 있습니다

   - 그래서 보안에 취약한 HTTP를 해결하기 위해 HTTPS가 등장하게 되었습니다

   - HTTPS는 HTTP Secure의 약자로 HTTP에 보안을 더한 것입니다

   - HTTPS는 데이터를 암호화하는 방식으로 보안을 취득합니다

3. 두 가지 암호화 방식, 대칭키와 비대칭키

   - 그렇다면 어떻게 HTTPS는 데이터를 암호화할까요?

   - 클라이언트가 서버로 암호화된 메시지를 보내고 서버는 받은 암호화된 메시지를 복호화 해야합니다

   ① 대칭키

      - 가장 간단한 방법은 클라이언트와 서버 모두 둘만 아는 비밀스런 암호화된 방식을 알고 있으면 됩니다

      - 예를 들어 메시지가 a -> b, b -> c, c -> d ... 로 암호화됐다면, 복호화는 반대 방식으로 진행하면 되기 때문입니다

      - 이렇게 둘 모두 같은 암호화된 방식(키)를 가지고 있다고 해서 이러한 방법은 '대칭키'라고 불립니다

      - 하지만, 네트워크를 통해 통신하는 클라이언트와 서버는 직접 만나지 않기에 둘만 아는 '키'를 공유할 수 없습니다

   ② 비대칭키

      - 이후 '비대칭키' 암호화 시스템이 등장했습니다

      - 비대칭키는 공개키와 개인키로 이루어져있습니다

      - 클라이언트-서버 구조에서 공개키는 클라이언트 모두에게 공개된 키이고 개인키는 서버만 가지고 있는 키입니다

      - 비대칭키의 암호화 방식은 공개키로 암호화된 메시지는 개인키로만 복호화할 수 있고, 개인키로 암호화된 메시지는 비공개키로만 복호화할 수 있는 것입니다

      - 그래서 클라이언트는 요청 메시지를 서버의 공개키를 이용해 암호화를 하고 서버는 개인키를 이용해서 메시지를 복호화합니다

      - 이렇게 되면 클라이언트의 요청 메시지가 탈취당하더라도 복호화할 수 없습니다

4. HTTPS를 이용한 전체적인 요청-응답 흐름

   - HTTPS는 HTTP와 보안 계층인 SSL/TLS 프로토콜이 결합된 것입니다(TLS는 SSL의 업데이트 버전이므로, 둘은 같다고 봐도 무방함)

   - 요청 응답 흐름

      ① 서버는 CA(Certificate Authority)로 부터 CA의 개인키로 암호화된 '인증서'를 발급받습니다 (이유 : 클라이언트가 서버와 통신할 때, 그 서버가 신뢰할 수 있는 서버임을 증명하기 때문임)

      ② 클라이언트는 서버와 통신하기 전 접속 요청을 보냅니다

      ③ 서버는 인증서를 클라이언트에 전송합니다

      ④ 클라이언트는 CA의 공개키르 인증서를 복호화하고 서버를 신뢰할 수 있습니다

      ⑤ 클라이언트는 인증서안에 있는 서버의 공개키로 임의의 대칭키를 생성해 암호화합니다

      ⑥ 클라이언트는 암호화한 대칭키를 서버에 보내면, 클라이언트와 서버는 같은 키인 '대칭키'를 갖게됩니다

      ⑦ 이제 이 대칭키를 이용해서 서버와 클라이언트는 안전하게 데이터를 주고받을 수 있습니다

   - 데이터를 바로 공개키로 암호화하지 않는 이유는 대칭키를 이용해서 암호화하고 복호화할 때 더 빠르기 때문입니다

HTTP부터 HTTPS까지 알아보며, 대칭키와 공개키에 대해서도 알아볼 수 있었습니다.