TIL 55일차 - [네트워크] 심화

Yoon Kyung Park·2023년 6월 28일

TIL

목록 보기

55/75

들어가기에 앞서 check 해보기

☑️ 네트워크 기초 및 HTTP

👉 TIL 31일차 참고
👉 TIL 32일차 참고
👉 TIL 33일차 참고

[IP/TCP/UDP]

패킷교환 방식의 이점에 대해 이해한다.

o
다른 사용자와의 전용선과 연결된 상태에서는 그 연결이 끊어질 때까지 기다렸다가 그 후에 상대방과 연결할 수 있는 회선 교환 방식의 비효율성을 보완하고자 미 국방성에서 진행한 아르파넷 프로젝트에서 패킷 교환 방식의 네트워크를 고안했다.

패킷 교환 방식은 '패킷(pack + bucket)'이라는 단위로
데이터를 잘게 나누어 전송하는 방식이다.
소포처럼 출발지와 목적지 정보 등 전송할 데이터의 정보가
담겨 있는 패킷을 전달하면,
패킷이 목적지를 향해 가장 효율적인 방식으로 이동하기 때문에
이전 회선 교환 방식처럼 전용선으로 할당되지 않는다.
따라서 보다 빠르고 효율적으로 데이터를 전송할 수 있다.

따라서 인터넷 프로토콜인 IP는 출발지와 목적지의 정보를
IP 주소라는 특정한 숫자값으로 표기하고,
패킷 단위의 데이터 전송하게 되었다.
IP의 비순서성, 비신뢰성에 대해 이해한다.

o
IP는 정확한 출발지와 목적지를 파악할 수 있다는 점에서 적절한 통신 방법이라고 생각되어질 수 있지만, 이러한 IP에도 한계가 있다.

패킷을 받을 대상이 없거나 서비스가 불능인 상태여도
클라이언트는 서버의 상태를 파악할 방법이 없기 때문에
패킷을 그대로 전송하게 되어 비효율적이다.
이는 IP의 비연결성에서 오는 한계이다.

또 다른 한계로 중간에 있는 서버가 데이터를 전달하는 중
장애가 발생하여 패킷이 중간에 소실될 경우,
이 역시 클라이언트는 파악할 방법이 없기 때문에
서버에서 응답이 올 때까지 마냥 기다려야 하는 비효율성이 발생한다.

또한, 전달 데이터의 용량이 클 경우 데이터를 패킷 단위로 나누어 데이터를 전달하게 되는데 이때, 패킷들은 중간에 서로 다른 노드를 통해 전달되어 클라이언트의 의도와 다른 순서로 서버에 패킷이 도착할 수도 있다.

이렇듯 IP는 비연결성과 비신뢰성의 한계를 가지고 있다.

TCP의 3 way handshake 및 그와 비교되는 UDP에 대해 이해한다.

o
이러한 IP의 한계를 3 계층인 네트워크 계층보다 한 단계 높은 전송 계층의 TCP가 보완할 수 있다.

TCP는 Transmisson Control Protocol의 약자로
전송 제어 프로토콜을 의미한다.

TCP는 장치들 사이에 논리적인 접속을 성립하기 위해
3 way handshake를 사용하는 연결지향형 프로토콜이다.

먼저 클라이언트는 서버에 접속을 요청하는 SYN(Synchronize) 패킷을 보낸다.

서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는
ACK(Acknowledgmen) 와 SYN가 설정된 패킷을 발송하고
클라이언트가 다시 ACK으로 응답하기를 기다린다.

클라이언트가 서버에게 ACK을 보내면,
이 이후로부터 연결이 성립되며 데이터를 전송할 수 있다.

만약 서버가 꺼져있다면, 클라이언트가 SYN을 보내고
서버에서 응답이 없기 때문에 데이터를 보내지 않는다.

현재에는 최적화가 이루어져 3번 ACK을 보낼때,
데이터를 함께 보내기도 한다.

이러한 TCP는 데이터 전송이 성공적으로 이루어진다면,
서버가 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.

또한, 패킷이 순서대로 도착하지 않는다면,
TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다.

이를 통해 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있다.

👇 [각 계층 별 데이터 이름]

+추가 학습)

TCP에서 데이터 패킷의 순서를 보장하는 방법은 다음과 같다.

데이터가 유실되어서 들어온 경우, 재전송 요청을 보낸다.

이 때에는 재전송을 받는 방법이 두 가지로 나뉜다.
1,2,3,4,5 순서로 패킷을 받는 상황을 예시로 들면,

1-1. Go-Back-N
: 순서가 잘못 들어온 패킷부터 다시 재전송 요청한다.

만약 데이터가 1,2,4... 이런 순서로 들어온다면,
4 이후로 들어온 패킷은 모두 폐기하고,
패킷 3부터 다시 받는 방식이다.
이 경우는 재조립 과정이 필요하지 않게 된다!

1-2. Selective Repeat
: 빠진 패킷만 재전송 요청

만약 데이터가 1,2,4... 이런 순서로 들어온다면,
빠진 패킷인 3만 재전송 요청을 한다.

만약 다른 패킷들은 순서대로 들어왔다면,
1,2,4,5,3 이런 순서로 패킷이 들어올 것이다.
이걸 상위 계층으로 전달할 때 순서대로 재조합해서 전달하게 된다.

1-1의 경우, 불필요해보이는 네트워크 요청을 추가로 보내야한다는 단점이, 1-2의 경우 패킷을 재조합하기 위한 추가 공간이 필요하다는 단점이 있다.
판단하기에 따라서 사용하는 방식이 달라질 수 있다고 한다.

2.데이터가 유실되지 않았지만 순서가 맞지 않게 들어온 경우, 재조합한다.

데이터 유실 없이 순서만 바뀌어서 들어왔다면,
그땐 재전송 요청을 보낼 필요 없이 순서대로 맞추기만 하면 된다.

정리하면,
데이터 재전송 요청을 하는 경우 : 1-1, 1-2
데이터를 재조합하는 경우: 1-2, 2

출처: 아고라 스테이츠 답변

[네트워크 계층 모델]

네트워크 통신을 계층별로 나눈 이유에 대해 이해한다.
o
OSI 7 계층 모델은 ISO(International Organization for Standardization)라고 하는 국제 표준화 기구에서
1984년에 제정한 표준 규격이다.

예전에는 같은 회사에서 만든 컴퓨터끼리만 통신이 가능했기 때문에
다른 회사의 시스템이라도 네트워크 유형에 관계없이
상호 통신이 가능한 규약, 즉 프로토콜(Protocol)이 필요했다.
그래서 ISO에서는 제조사에 상관없이 '공통으로 사용'할 수 있는
네트워크 표준 규격을 정의헸다.

OSI 7계층 모델은 네트워크를 이루고 있는 구성요소들을
7단계로 나누고, 각 계층의 표준을 정했다.
OSI 7계층 모델의 목적은 표준화를 통하여
- 포트, 프로토콜의 호환 문제를 해결하고,
- 네트워크 시스템에서 일어나는 일을
  해당 계층 모델을 이용해 쉽게 설명할 수 있다.
- 네트워크 관리자가 문제가 발생했을 때
  이것이 물리적인 문제인지, 응용 프로그램과 관련이 있는지 등 원인이 어디에 있는지 범위를 좁혀 문제를 쉽게 파악할 수 있다.
  
  👇 [OSI 7계층과 TCP/IP 4계층]
👇[OSI 7계층별 의미]

👇 [TCP/IP 4계층별 의미]

통신 과정에서 일어나는 데이터 캡슐화에 대해 이해한다.

o

👇 [데이터 캡술화]

OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고받는다.
각 계층은 독립적이므로 데이터가 전달되는 동안에
다른 계층의 영향을 받지 않는다.

데이터를 전송하는 쪽은 데이터를 보내기 위해서
상위 계층에서 하위 계층으로 데이터를 전달한다.
이때 데이터를 상대방에게 보낼 때,
각 계층에서 필요한 정보를 데이터에 추가하는데
이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 한다.
이렇게 헤더를 붙여나가는 것을 캡슐화라고 합니다.

마지막 물리 계층에 도달하면,
송신 측의 데이터링크 계층에서 만들어진 데이터가
전기 신호(0과 1의 언어)로 변환되어 수신 측에 전송된다.

데이터를 받는 쪽은 반대로 하위 계층에서 상위 계층으로
각 계층을 통해 전달된 데이터를 받는다.
이때 상위 계층으로 데이터를 전달하며,
각 계층에서 헤더(데이터링크 계층에서는 트레일러)를 제거해 나가는데 이것을 역캡슐화라고 한다.
역캡슐화를 거쳐 마지막 응용 계층에 도달하면,
드디어 전달하고자 했던 원본 데이터만 남게 된다.

[HTTP] ⭐️⭐️

응용 계층의 대표적인 프로토콜인 HTTP에 대해 알아본다.
앞서 설명했듯이 HTTP는 웹 사이트를 이용하기 위해 사용한다.
따라서 프론트엔드, 백엔드 상관없이 웹 개발은 모두 HTTP를 기반으로 하기에 중요한 특징들을 알아두는 것이 중요하다.

더불어 HTTP 메시지 구성 중 하나인 헤더에 대해 학습한다.
그리고 바디를 설명하는 표현 헤더와 요청(Request)과 응답(Response)에서 주로 쓰이는 헤더 및 콘텐츠를 협상하여
요청할 수 있는 여러 협상 헤더에 대해서도 학습한다.

HTTP 메시지 구조를 이해한다.

o
HTTP 메시지는 헤더와 바디로 구분할 수 있다.

HTTP 바디에서는 데이터 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달한다.

여기서 데이터를 실어 나르는 부분을 페이로드(Payload)라 한다.

표현은 요청이나 응답에서 전달할 '실제 데이터'를 뜻하며
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
👇 [HTTP 헤더와 바디]

👇 [주요 헤더 구조]

HTTP의 특징을 이해한다.
o
- 클라이언트-서버 구조 (Request-Response 구조)
  : 클라이언트는 서버에 요청을 보내고, 응답을 대기한다.
  서버는 클라이언트의 요청에 대한 결과를 만들어 응답한다.
- 무상태(stateless) 프로토콜
  : HTTP에서 서버는 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.
  이러한 무상태성은 클라이언트가 요청 시,
  필요한 정보를 추가적으로 데어터에 담아 보내기 때문에
  서버거 클라이언트의 상태를 보존하지 않아도 되므로
  특정 서버에만 요청을 보낼 필요 없이 아무 서버에 요청할 수 있다.
  
  또한, 서버에 장애가 발생해도 다른 서버에 응답을 전달하면 되기 때문에
  클라이언트가 다시 요청을 할 필요가 없다.
  따라서 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에
  무한대로 서버를 확장할 수 있다(스케일 아웃)는 장점이 있지만,
  클라이언트가 추가적으로 데이터를 전송해야 한다는 단점이 있다.
  
  또한, 로그인이 필요 없는 단순한 서비스 소개 화면과 같은 경우에는
  모든 것을 무상태로 설계할 수 있지만,
  로그인이 필요한 서비스인 경우, 유저의 상태를 유지해야 하므로
  브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다.
  따라서 최소한의 상태 유지가 필요하다는 한계를 가진다.
  
  cf) 상태 유지(stateful)
  : 클라이언트의 상태를 기억하고 보존하기 때문에,
  상태 유지가 되어야 하는 프로토콜이라면,
  클라이언트의 요청을 항상 특정 서버가 응답해야 한다.
  만약 중간에 서버가 달라질 경우,
  클라이언트의 요청 및 정보를 미리 알려줘야 하고,
  서버에 장애가 발생할 경우,
  유지되었던 상태 정보는 다 날아가 버리므로 처음부터 다시 요청해야 한다.
- 비연결성(connectionless) 프로토콜
  : TCP/IP의 경우 기본적으로 연결을 유지한다.
  연결을 유지하는 모델(Connection Oriented)에서는 클라이언트가 요청을 보내지 않더라도 계속 연결을 유지해야 함으로 연결을 유지하는 서버의 자원은 계속 소모하게 된다.
  
  비연결성을 가진 모델(Connectionless)인 HTTP에서는
  실제로 요청을 주고 받을 때만 연결을 유지하고,
  응답을 주고 나면, TCP/IP 연결을 끊는다.
  이는 최소한의 자원으로 서버 유지를 가능하게 한다.
  
  따라서 HTTP는 기본적으로 연결을 유지하지 않는 모델로
  일반적으로 초 단위 이하의 빠른 속도로 응답한다.
  트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우에
  이러한 비연결성의 특징은 효율적으로 작동한다.
  하지만, 트래픽이 많고, 큰 규모의 서비스를 운영하는 경우에는
  이러한 비연결성은 한계가 있다.
  
  또한, 웹 브라우저로 사이트를 요청하면,
  HTML 뿐만 아니라 JavaScript, CSS, 추가 이미지 등
  수많은 자원이 함께 다운로드 된고, 해당 자원들을 각각 보낼 때 마다
  연결을 끊고 다시 연결하고를 반복해야 함으로 비효율적이다.
  
  이러한 비연결성의 한계는
  HTTP 지속 연결(Persistent Connections)로 해결되었다.
👇 [HTTP 초기]
: HTTP 초기에는 각각의 자원을 다운로드하기 위해
연결과 종료를 반복해야 했다.

👇 [현재]
: HTTP 지속 연결에서는 연결이 이루어지고 난 뒤
각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다.

HTTP의 무상태성과 비연결성에 대해 이해한다.

o (위에서 설명)
HTTP 헤더 중 바디를 설명하는 헤더인 표현헤더에 대해 이해한다.

o
HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다.

표현 헤더는 표현 데이터의 형식, 압축 방식, 자연 언어, 길이 등을 설명하는 헤더로 요청, 응답 둘 다 사용한다.
HTTP 헤더 중 요청과 응답에서 주로 사용되는 헤더에 대해 이해한다.
o
- 요청(Request)에서 사용되는 헤더
  : From(유저 에이전트의 이메일 정보), Referer(이전 웹 페이지 주소), User-Agent(유저 에이전트 애플리케이션 정보), Host(요청한 호스트 정보, 도메인), Origin(서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄), Authorization(인증 토큰을 서버로 보낼 때 사용하는 헤더)
- 응답(Response)에서 사용되는 헤더
  : Server(요청을 처리하는 ORIGIN 서버의 소프트웨어 정보), Date(메시지가 발생한 날짜와 시간), Location(페이지 리디렉션), Allow(허용 가능한 HTTP 메서드), Retry-After(유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간)

HTTP 헤더 중 서버에 요청하는 콘텐츠를 협상할 수 있는 협상헤더에 대해 이해한다.

o
협상 헤더는 요청 시에만 사용한다.

예를 들어, 한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)이 적용되지 않았다면,

서버는 요청으로 받은 우선순위가 없으므로
기본 언어로 설정된 영어로 응답한다.
만약, 클라이언트에서 Accept-Language로 KO를 작성해 요청한다면
서버에서는 해당 우선순위 언어를 지원할 수 있기 때문에
한국어로 된 응답을 돌려준다.

그러나 지원하는 언어를 요청하는 단순한 경우가 아닌
서버에서 지원하는 언어가 여러 개일 때
클라이언트가 최우선으로 선호하는 언어가 지원되지 않는다면,
1부터 0까지 우선순위를 부여하면 된다.
이를 토대로 서버는 응답을 지원한다.

이를 이용해 서버에 우선순위 요청을 하게 되면,
1순위인 한국어를 서버에서는 지원하지 않지만
2순위인 영어를 지원하기에 서버에서는 우선순위에 있는 영어를
독일어보다 클라이언트가 선호하기에 영어로 응답을 주게 된다.

👇 [Accept-Language 협상 요청 예시]

[HTTPS] ⭐️⭐️

왜 HTTPS가 HTTP보다 안전한 지 이해한다.

o
HTTPS는 HTTP Secure의 약자로,
기존의 HTTP 프로토콜을 더 안전하게(Secure) 사용할 수 있음을 의미한다.
HTTPS가 HTTP와 달리 요청과 응답으로 오가는 내용을 암호화하기 때문이다.

👇 [ HTTP 예시1 ]

HTTP로 보낸 요청을 'wireshark'라는
패킷 분석 프로그램을 이용하여 캡처한 것이다.
이미지를 확인해 보면, email과 password 같은 값을
그대로 볼 수 있는 것을 알 수 있다.
이는 제3자가 HTTP 요청 및 응답을 탈취한다면,
전달되는 데이터의 내용을 그대로 확인할 수 있다는 뜻이기도 하다.

👇 [ HTTPS 예시1 ]

위 이미지와 동일한 요청을 HTTPS 프로토콜로 보냈을 때를 확인한 것으로
똑같은 요청임에도 데이터가 암호화되었음을 알 수 있다.
따라서 HTTPS 요청 및 응답은 중간에 제3자에게 데이터가 탈취되더라도
그 내용을 알아볼 수 없다.
HTTPS의 암호화 방식에 대해 이해한다.

o
데이터를 암호화를 할 때는 암호화할 때 사용할 키와
암호화한 것을 해석(복호화)할 때 사용할 키가 필요하다.
이때 암호화와 복호화할 때 사용하는 키가 동일하면,
대칭 키 암호화 방식이라 하고,
암호화와 복호화할 때 사용하는 키가 다르다면,
공개 키(비대칭 키) 암호화 방식이라고 한다.
HTTPS에서 사용하는 대칭키, 비대칭키 방식에 대해 이해한다.

o
대칭 키 암호화 방식은 하나의 키만 사용한다.
암호화할 때 사용한 키로만 복호화가 가능하다.
두 개의 키를 사용해야 하는 공개 키 방식에 비해서
연산 속도가 빠르다는 장점이 있지만,
키를 주고받는 과정에서 탈취당했을 경우에는
암호화가 소용없어지기 때문에 키를 관리하는데 신경을 많이 써야 한다.

반면, 비대칭 키 암호화 방식은 두 개의 키를 사용한다.
암호화할 때 사용한 키와 다른 키로만 복호화가 가능하다.

이때 두 개의 키를 각각 공개 키, 비밀 키라고 부른다.
여기서 공개 키는 이름 그대로 공개되어 있기 때문에

누구든지 접근 가능하다.
누구든 이 공개 키를 사용해서 암호화한 데이터를 보내면,
비밀 키를 가진 사람만 그 내용을 복호화할 수 있다.
보통 요청을 보내는 사용자가 공개 키를, 요청을 받는 서버가 비밀 키를 가진다. 이때, 비밀 키는 서버가 해킹 당하는 게 아닌 이상 탈취되지 않는다.

이러한 공개 키 방식은 공개 키를 사용하여
암호화한 데이터가 탈취당한다고 하더라도,
비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 더 좋다. 하지만 대칭 키 방식 보다 더 복잡한 연산이 필요하여 더 많은 시간을 소모한다는 단점이 있다.
직접 로컬에서 HTTPS 인증서를 발급할 수 있다.

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

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

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

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

출처: codestates

실습

들어가기에 앞서 check 해보기

☑️ HTTP에 대한 이해

현업에서는 HTTPS 프로토콜을 사용하는 것이 일반적이고,
특히 HTTPS 프로토콜은 인증의 중요한 부분을 차지한다.

로컬 환경(localhost)에서 인증서를 생성하고,
인증서를 이용해 HTTPS 서버를 만든다.
o

HTTPS의 개념을 이해할 수 있다.
o

HTTPS가 왜 인증에서 필요하고, 왜 사용해야 하는지 이해할 수 있다.
o

key와 cert의 다른 점은 무엇인가?
o
key는 비대칭 암호화 키고 cert는 CA에서 받은 인증서를 의미한다.

실습결과

[Bare minimum 실습]

👇 이 방법대로 하여 서버 연결은 잘 되었다.

그러나 Advanced에서 ngrok을 이용하여 HTTPS로 터널링을 하려고 했는데 토큰을 등록하는 단계에서 잘못된 거 같았다.

처음에는 ngrok config add-authtoken <token> 이 명령어를 입력했을 때,
"parse error near '\n'"이 라는 메시지가 떠서 검색해보니
'<>'를 지우고 하면 된다고 해서
그대로 했는데 ERROR: Your authtoKen: token 이라는 메시지가 뜨는 걸 보니 "token"이란 값이 들어가서 오류를 일으키고 있는 것 같았다.
그래서 다 지우고 다시 하려고 했는데
ngrok은 프로젝트 폴더 안이 아니라 전역으로 설치되는거라서
폴더를 지운다고 해도 삭제가 안 될 거라고 했다.. 🥲

그래서 다른 방법으로 다음과 같이 진행해보았다.
터미널에서 ngrok config edi을 입력하면,
터미널에서 텍스트를 수정할 수 있게 된다.

authtoken: token 으로 되어 있는걸
authtoken: "" 이렇게 수정해준 다음,
control + X 눌러서 끝내고, Y 눌러서 저장하고, 엔터 눌러서 종료하면
토큰 값이 빈 값으로 바뀐다.
그러면 토큰 수정돼서 ngrok http로 명령어를 입력하면 잘 되어야 하는데..!
터미널에서는 서버 조회에 대한 요청은 잘 되는 것 같으나.. 🤔

브라우저에서 보이는 화면에는 이러한 에러 메시지가 뜬다.
그리고 다시 보이는 토큰 관련 에러 메시지... 😫

결국에는 ngrok에 회원가입 한 후에 새로운 토큰을 생성 받아서 등록한 후,
진행해야 하는 것 같다.