개발공부 기록지

더 멀리, 라우터

네트워크의 중계자, 라우터

LAN은 가정집이나 회사같은 소규모 네트워크이고, 이것이 모인 것을  WAN

점점 더 규모가 커지면서 흩어진 LAN을 연결하고 LAN으로 데이터가 올바르게 전달할 수 있게 돕는 중간 장치가 필요

그래서 탄생 한 것이 라우터(Router)

Router : 데이터가 원하는 목적지로 원할하게 도착할 수 있도록 적절한 통신 경로를 안내하는 장치

라우터의 종류 - 가정에 있는 공유기, 인터넷 제공 업체에서 관리하는 라우터 장치 등등

라우팅 테이블로 최적의 경로 찾기

라우터는 가장 빠르게 이동할 수 있는 경로를 찾아 안내

어떻게??

라우팅 테이블(Routing table)

최종 목적지의  IP주소와 목적지에 도달하기 위해 경유해야 할 인근 라우터의 정보가 담긴 테이블 <라우팅 테이블> 을 이용.

가장 빠른길을 찾다 보면 데이터가 네트워크 속에서 무한 루프가 발생할 수 도있다.

이를 방지하기 위해서 TTL(time to live) 라는 유효기간을 각 데이터마다 할당

진짜 고유번호, MAC 주소

MAC (media aceess control) 주소는  네트워크를 사용하는 기기라면 모두 가지고 있는 주소

이 주소는 장치들을 서로 인식하고 식별하기 위해 사용

MAC 주소의 구조 (8 비트)

a1:b2:c3:d4:e5:f6

a1:b2:c3 = 제조사 식별자

a1:b2:c3 = 실제 고유번호

HTTP 는 상태가 필요해

상태 프로토콜 (state protocol) - 상태를 저장하는 프로토콜 : TCP

무상태 프로토콜 (stateless protocol) - 상태를 저장하지 않는 프로토콜: IP, UDP, HTTP

• 장점: 상태를 어떻게 저장할지 고려할 필요가 없어서 서버를 단순하게 설계가능
• 단점: 요청마다 추가 정보를 전달

HTTP 외부에 따로 저장소를 두어 그곳에서 상태를 저장할 수 있도록 관리하고, 필요에 맞게 서버에 상탤르 전달

--- HTTP 단점 보완

브라우저 안의 작은 조각, 쿠키

데이터를 저장하는 방식 중 하나 인 쿠키

브라우저에 데이터를 저장하는 이유

  신속성과 서버 비용절감

숨은 작은 조각, 쿠키

세션 쿠키(session cookie) : 브라우저가 종료될때 함께 사라짐

영구 쿠키 (persistant cookie) : 만료 기간이 존대, 해당 기간이 지나면 삭제

쿠키의 단점

보안에 취약

퍼스트 파티 쿠키 - 방문한 웹사이트에서 직접 발행한 쿠키

서드 파티 쿠키  - 제 삼자가 발행 한 쿠키

개징정보 문제

 쇼핑한 내용과 유사한 광고가 뜨는 모습 <- 서트 파티 쿠키 때문

쿠키를 넘어서, 웹 스토리지와 IndexdedDB

더 많이 더 빠르게, 웹 스토리지

<그림 첨부>

웹 스토리지는 데이터의 유지시간에 따라 두 가지로 분류

• 로컬 스토리지 : 자동 로그인처럼 지속해서 사용해야 하는 데이터
• 세션 스토리지 : 일회성 정보처럼 잠깐만 필요한 데이터

로컬 스토리지에 데이터를 추가하기 위해서는  → localStorage.setItem('key', 'value');

특정 키의 값만 삭제 → removeItem('key')

웹 페이지내 모든 로컬 스토리지 값을 삭제 → clear()

브라우저 안의 데이터 베이스, IndexedDB

• 브라우저에 내장된 데이터베이스 이며, 웹 스토리지보다 더 강력하게 데이터를 저장하는 방법
• 많은 양의 데이터를 체계적으로 관리할 수 있게 해줌 → 물류창고 같은 느낌
• 클라이언트 단에서 자바스크립트로 조작 가능
• 웹 스토리지나 쿠키는 키값을 알아야 값을 찾는 것이 가능하지만, IndexedDB 는 cursor라는 개념을 이용하여 키를 몰라도 찾는 것이 가능

세션으로 안전하게 저장하기

브라우저에서 데이터를 저장하면 다른사람들이 쉽게 접근할 수 있다는 문제점이 있다.

서버에 데이터를 저장하는 세션

• 사용자 정보를 서버 측에 저장하는 방법을 말할때도 세션(Session)이라고 한다.
• 서버에 일시적으로 데이터를 저장할 수 있는 기술 
• 세션 정보를 저장하는 장소는 쿠키, 세션은 쿠키에 기반한 관계
• 클라이언트에 세션 정보를 저장하는 과정에서 쿠키사용

??? 쿠키는 실제 데이터를 클라이언트에 저장, 세션은 서버에 저장

웹의 짝궁 HTTP

커피숍에서 주문없이 자리에만 앉아 있으면 커피는 제공되지 않는다.

→ 요청(주문)이 없으면 응답(커피)이 없다.

Http(hypertext Transfer Protocol)??

웹 브라우저와 웹 서버간에 데이터를 주고 받기 위해 사용하는 프로코콜

하이퍼텍스트 형태의 데이터뿐만 아니라 이미지나 동영상 형식도 전달가능

특징

• 클라이언트/서버 모델을 따른다
  • 서로 관계를 맺고 있는 컴퓨터가 클라이언트와 서버라는 두 역할로 구분된다.
  • 클라이언트와 서버는 서로 HTTP 메세지를 주고 받으며 통신을 하는데 이걸 요청/응답 메세지라고 한다
    • 클라인언트 → 서버 (요청 : 커피 주문)
    • 서버→ 클라이언트 (응답: 커피)
• 상태를 가지지 않는다(stateless), 비연결성 프로토콜
  • 과거의 대화내용을 기억하지 않는다.
  • 첫번째 통신에서 데이터를 주고 받아도 두번째 통신에서는 첫번째 통신에서 주고 받은 데이터를 유지하지 않는다.

장점 : 데이터를 유지하는 비용이 없다

단점 : 요청 할 때마다 3방향 핸드쉐이크를 해야한다.

HTTP의 구조

요청 메세지의 구성요소 설명

헤더

HTTP 메세지에 대한 추가 정볼르 제공하기 위해 사용

빈줄

헤더와 본문을 구별하기 위함

본문

요청 메세지에서는 채워져 있는 경우가 드뭄

사용되는 경우?  회원가입에 필요한 정보를 담기 위한 경우와 같은 경우에 채워져 있다. 

응답 메세지의 구성요소 설명

상태코드

클라이언트 요청에 따른 서버의 응답상태를 숫자로 나타낸것

참고:  https://joey0203.tistory.com/28

본문

요청에 관한 자원이 표시되는 곳

자원이 유형에 맞는 형식으로 표시 ( HTML 코드, 이미지, 동영상, ... )

GET vs. POST,  PUT vs. PATCH

요청 메서드의 종류

HEAD :  HTTP 헤더 정보만 요청. 웹 서버가 정상적으로 작동하는지 등 서버 상태를 미리 확인 하기 위해 사용

PUT / PATCH

• PUT : 특정 데이터 전체를 교체할 때(수정할 때)
• PATCH : 특정 데이터의 일부를 교체할 때 (수정할 때)

      참고 그림

OPTION : 서버 측에서 제공 할 수 있는 메서드가 무서인지 알기 위해 사용

 ex) 클라이언트에서 option 메서드를 달아 요청을 보내면  서버에서 다음과 같이 응답  "Allow : GET, POST, HEAD"

안전한 메서드, 멱등성을 가진 메서드

안정성 : 클라이언트가 요청을 해도 서버의 자원(데이터)이 변하지 않는 특성을 의미

• 안정성 O  = GET, HEAD, OPTIONS 
• 안정성 X  =  POST, PUT, PATCH, DELETE

멱등성 (idempotent) : 연산을 여러 번 적용을 해도 결과가 달라지지 않는 특성

• 멱등성  O = GET, HEAD, PUT, DELETE, OPIONS
• 멱등성  X = POST, PATCH

헤더가 왜 중요할까?

TCP/IP 와 HTTP의 공통점은 바로 헤더가 있다는 점.

헤더는 데이터에 대한 추가 정보를 제공하며, 헤더가 커지면 덩달아 전체 데이터의 크기도 커지기 때문에 필요한 정보만 담는 것이 중요하다.

그러므로 헤더에는 해당 데이터에 대한 핵심 정보를 바로 파악할 수 있는 정보가 들어 있다.

HTTP 헤더의 특징

• 사람이 읽을 수 있는 형태로 작성
• 자유로운 형식
• 클라이언트와 서버가 필요한 만큼 헤더를 작성 가능
  • 각 정보의 위치가 정해져 있는 것 이 아니라 원하는 위치에 알아서 필요한 만큼 정보 입력 가능
  • 급식판이 아닌 뷔페에 가면 있는 큰 접시와 같은 느낌.

크롬 브라우저에서 직접 헤더 확인하기

F12 를 누른 후 -> Network 탭 선택 -> 보이는 데이터를 선택하 -> header 탭을 선택하면 확인 가능 

HTTP 헤더의 종류

<그림>

공통 헤더 (General header)

• 요청 메세지와 응답메세지가 모두 적용되는 헤더
• 대표적인 헤더 예시
  • Date - 메세지가 발생한 날짜와 시각을 표현
  • Cache-Control - 기존에 받은 데이터를 저장할지 여부를 정함

요청 헤더 (Request header)

• 요청 메세지를 작성
• 클라이언트에 대한 정보 또는 변경될 데이터에 관한 내용을 포함
• 대표적인 헤더 예시
  • Host - 데이터를 요청하는 서버의 호스트 이름
  • User-Agent - 클라이언트의 정보

응답 헤더 (Response header)

• 응답 메세지에 대한 정보를 담고 있는 헤더
• 대표적인 헤더 예시
  • 웹 서버의 종류(server) 등 서버에 대한 정보가 있음

엔티티 헤더 E(Entity header)

• 메세지 본문에  대한 정보를 포함하는 헤더
• 대표적인 헤어 예시
  • 본문의 길이 ( Content-length)
  • 자원의 미디어 타입(Content-type)
  • 본문의 언어(content-language)

(추가)

accept - 접두어 : 이 헤더는 이런 응답만 허용하겠다는 의미

상태 코드로 통신 상태 한눈에 파악하기 

상태코드란?

클라이언트의 요청에 따른 서버의 응답 상태를 세 자리 숫자로 나타낸것

예) Status Code : 200 

5 가지 클래스로 알아보는 상태코드

<사진>

1XX Class  조건부 응답, 웹 서버가 현재 요청을 받았으며 작업을 진해하고 있다는 의미

2XX Calss  클라이언트가 요청한 작업을 서버가 성공적으로 처리 했음을 의미

3XX Calss  리다이렉션 완료 응답, 요청을 완료하기 위해 재전송이 필요하는 의미

4XX Class 클라이언트 측에 오류가 있음을 의미

5XX Class 서버가 요청을 수행하지 못했을 을 의미

자주 쓰이는 상태코드 설명 여기 참고 : https://joey0203.tistory.com/28

보안을 책임지는 요소들 : SSL, TLS, HTTPS

HTTP의 한계, 보안

HTTP의 문제점

1. 누구나 볼 수 있게 암호화하지 않은 상태로 전송

2. 통신 상대를 확인 하지 않는다

이로 인한 대표적인 보안문제 -> 중간자 공격 (Man in the middle attack, MITM)

네트워크 통신 도중 중간자가 침입해 통신 내용을 도청하거나 조작하는 공격 기법.

ex) 중간에서 공인인증서 위조, 회원가입시 비밀번호 유출

해결책 -> HTTPS (Hypertext Transfer Protocol Secure)

보안을 책임지는 HTTPS

누구나 볼 수 있었던 메세지를 통신하는 당사자만 볼 수 있게 암호화

URL 이 https:// 로 시작하고 앞에 자물쇠 아이콘이 달린모습으로 우리에게 보인다.

SSL과 TLS는 무엇이 다를까?

HTTPS의 암호화를 담당하는 곳

-> SSL (Secure Socket Layer), 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있게 돕는 보안 계층

TLS (Transport Layer Security) ? 

SSL 과 같은 보안 프로토콜, SSL 3.0 버전 다음 부터 등장한 이름

대다수의 보안 프로토콜이 TLS 사용

대칭키, 공개키로 안전하게 암호화하기

대칭키 

하나의 키로 암호화와 복호화를 둘 다 할 수 있는 암호화

장점 : 공개키 방식에 비해 속도가 빠르다

단점 : 서로 키를 안전하게 교환하기가 어렵다, 중간에서 누군가 키를 가로챌 위험 존재 

공개키 

대칭키 단점을 보완하기 위해 탄생

서로 다른 키 두 개로 암호화와 복호화를 한다.

사용하는 두개의 키는 공개키, 개인키, 이 두 키는 늘 한 쌍으로 동작

>  암호화 / 복호화 방법

상자를 빨간 (파란) 열쇠로 잠구면,
남아있는 파란 (빨간) 열쇠로만 상자를 열기 가능 

> 장점 : 대칭키보다 더 안전하게 데이터를 주고 받을 수 있다.

> 단점 : 암호화 과정이 복잡하여 속도가 느리다.

SSL 동작 과정 : 핸드셰이크, 세션, 세션종료

1 단계 : 서버에게 인사 = 서버에 데이터 전송
             → < 랜덤데이터 : "Hi",  현재 지원가능한 암호화 방식을 서버에 전달>

2 단계 : 클라이언트에 데이터 전송
             → < 랜덤데이터 : "Hello", 지원가능한 암호화 방식, 발급 받은 서버 인증서 >
                   *인증서 = CA(Certificate Authority) 에서 발급받은 문서 : 서버가 신뢰할 수 있는지 보장하는 문서  

3 단계 : 인증서 검증, 인증서 복호화

             → CA에서 공유하는 공개키로 인증서 복호화

4 단계 : 대칭키 생성 및 암호화하여 서버에 전달

             → 임시 대칭키 생성 ( 주고 받은 랜덤데이터를 이용 : "Hi" + "Hello"),  공개키로 암호화하여 서버에 전달

5 단계 : 비밀키로 복호화( 암호 해독 ) 

             → 서버가 가지고 있던 비밀키로 암호를 해독하여 클라이언트와 같은 임시 대칭키를 보유

6 단계 : 세션키 생성
             → 클라이언트와 서버가 가지고 있는 키를 일련의 과정을 거쳐서 세션키로 변경

SSL 은 두 개의 암호화 방식 (대칭키 기법, 공개키 기법)을 사용해 신뢰할 수 있는 데이터 통신환경을 제공

간략히 보는 HTTP 변천사

초기 HTTP 

GET 메소드만 지원

HTTP의 시작, HTTP/1.0

GET + HEAD, POST 지원

클라이언트와 서버간의 원활한 통신 가능

요청 마다 새로운 연결을 맺아야 한다.

표준,  HTTP/1.1

• 지속적 연결 상태 ( Persist Connection) :  요청마다 TCP 연결을 해야하는 문제(1.0 버전)를 해결, 메모리 자원 절약
• 파이프라이닝 ( Pipelining) : 응답이 도착해야만 다음 요청을 보낼수 있는 문제(1.0 버전)을 해결, 통신 지연문제 해결

더 빠르게,  HTTP/2

SPDY 프로토콜을 도입하여  성능 및 속도 개선

성능 및 속도를 개선한 방법

1. 스트림 다중화 (Multiplexed Streams)  한 연결 안에서 여러 개 의 메세지를 주고 받을 수 있게 됨

2. 서버 푸쉬(server push)  이용하여 클라인언트가 굳이 요청하지 않아도 서버에 미리 필요한 리소스를 푸쉬 가능

3. 바이너리 프레이밍 (binary framing)  HTTP 메세지를 더 작은 단위로 쪼개 010101 같은 바이너리 형태로 캡슐화 

       이로 인해서 스트림 다중화와 서버 푸쉬가 가능해졌다.

따끈한 새 버전, HTTP/3

HTTP/2 에서 해결하지 못한 문제를 해결

* TCP 는 데이터를 무조건 순서대로 처리

(문제) HOLB(head of line blocking) :

중간에 일부 데이터가 손실되면 이를 해결하는 동안 다른 데이터 처리 불가능

병목현상 발생

해결책

QUIC ( Quick UDP Internt Connection) : TCP 가 아닌 UDP 기반에서 작동하는 프로토콜

• 빠른 속도 보장
  • TCP 의 3 방향 핸드쉐이크 생략
  • TLS 에서 암호화과정 생략
• 데이터 검증을 통한 신뢰성 보장

• 멀티플렉싱(Multiplexing) 기법 : 데이터를 독립적으로 다룸 -> TCP 에서의 병목현상 해결

• TLS 대체 : TLS 에서 데이터 암호화과정 생략 됨

4장에서 IP 는 데이터 전달을 제외한 나머지는 신경을 안쓴다고 하여 데이터가 완전히 받을 수 있을지 의문이 드는데

TCP 가 언제 어디서든 데이터를 온전히 가져다 주기위한 프로토콜이다.

TCP :전송 제어 프로토콜

• 신뢰성있는( 언제 어디서든 데이터를 온전히 가져다 줄거라는 믿음) 있는 통신을 위한 프로토콜
• 데이터 유실의 오류를 감지하고 해결해 데이터가 온전히 전송 될 수 있게 해준다.

패킷 유실의 문제를 해결하는 방법?

• TCP가 패킷마다 번호를 붙여서 무엇이 사라졌는지 확인을 한다.
• TCP 에서 데이터를 주고 받을 때 확인 절차를 추가
  • 서버가 클라이언트에게 데이터를 잘 받았다는 메세지를 받았는 지 확인하고 받지 못했다면 다시 데이터를 보내어 확실하게 클라이언트가 데이터를 받을 수 있게 보장.

※ 패킷, 클라이언트?

패킷

데이터를 전송할때 사용되는 작은 컨테이너 개념,

네트워크 통신을 할 때 사용되는 작게 분할된 데이터 조각으로 네트워크에서 전송하는 데이터의 기본 단위

클라이언트

서버에서 보내는 서비스 요청

지금 데이터 상태는? 헤더와 플래그

해당 데이터에 대한 정보가 담겨 있는 헤더 (header)

패킷의 상태를 알리는 목적의 헤더 정보인 정보 플래그(flag) -> 다른 기기에 신호를 전달하기 위한 용도

TCP 헤더의 플래그 종류

• ACK (Acknowledgement) : 앞서 받은 데이터를 잘 처리 했다는 의미
• SYN (Synchronize) : 연결을 요청하는 플래그
• FIN (Finish) : 통신이 마무리되어 연결의 해제를 요청하는 플래그

TCP 헤더 전체 그림

TCP에서 연결을 수립하고 해지하는 과정

시작은 3방향 핸드쉐이크

 3번의 메세지 교환을 통해서 클라이언트와 서버간의 연결을 수립하기 위해 준비하는 방식

아래의 그림과 같이 클라이언트와 서버가 서로 데이터를 주고 받을 수 있는 상태인지 확인을 하는 방식

마무리는 4방향 핸드쉐이크

4번의 메세지 교환을 통해서 클라이언트와 서버간의 연결을 끝내는 방식

연결종료 신호 (FIN) 을 받고 time_wait를 하는 이유는 클라이언트 쪽에서 혹시 모를 일 (예를 들어 아직 도착하지 못한 패킷)에 대비 해 잠시 기다렸다가 최종적으로 서버에 응답(ACK) 를 보내서 종료 시킨다.

사이 좋게 데이터를 주고 받는 방법

흐름제어

데이터를 주고 받을 때 전송자가 빠르거나 수신자가 빠를 수도 있다. 이때 상호간의 속도를 무시하고 전송하면 데이터 손실 같은 오류가 발생 할 수 있다. 그러므로, 전송자와 수신자의 속도에 따라 데이터 전송 속도를 조절 하는 것 을 말한다.

정지-대기방식

데이터의 손실? 을 막기 위해 클라이언트와 서버간에 아래와 같은 확인 절차를 거치는 방식.

서버 →(데이터)→ 클라인언트 →(응답:ACK)→ 서버

장점 : 데이터가 확실하게 전송되었는지 확인 가능하다.  신뢰성이 높다.

단점 : 하나하나 확인을 해야 하므로 시간이 올래 걸린다. 효율성이 떨어진다.

슬라이딩 윈도우 방식

한번에 여러개의 데이터를 보내서 하나하나 확인을 하지 않아도 되게하는 방식으로 아래의 그림과 같이 작동한다.

데이터를 윈도우 크기만큼 전송하고 수신자가 수신한 데이터에 대한 응답을 보내는 데 이때 헤더에 데이터 번호가 적혀있다.

윈도우라고 부르는 이유는 확인된 데이터 번호 다음으로 이동하여 다시 데이터를 전송하는 방식이므로 슬라이드 윈도우 하고 정함.

주로 전송자가 수신자의 윈도우 크키를 파악해서 전송한다.

혼잡 제어로 네트워크 나누어 쓰기

혼잡 제어

혼잡은 '수신자'가 전송자가 데이터를 보냈지만 네트워크 처리속도가 느려서 '재전송'을 요청하고 전송자는 데이터가 유실되었다고 판단하여 데이터를 '재전송'하는 상황에서 발생한다. → 네트워크 내에 패킷의 수가 과도하게 증가

이러한 혼잡을 제어하기 위한 기능

혼잡 제어 원리

천천히 데이터를 전송하다가 수신자가 잘 받으면 속도를 상승시킨다. 수신자의 데이터 수신 상태에 따라 속도를 조절

예를 들어 4번 데이터를 전송할 차례인데 수신자가 2번 데이터까지만 받았을때 속도를 늦춘다.

합 증가/감소

• 수신자가 잘받았는 신호가 올때 마다 윈도우 크기를 1씩 증가
• 신뢰성 높다
• 속도를 증가시키는데 시간이 걸린다.

느린시작

• 2배씩 증가하여 시간이 지날수록 많은 양의 데이터 전달 가능.
• 느린시작인 이유 : 기존의 TCP 방식보다 시작이 느려서이다. 
  • 한번에 수신자가 받을 수 있는 최대 윈도우로 보내기 보다 1 부터 시작

더 빠르게 UDP (User Datagram Protocol)

TCP vs UDP

UDP는

전송자와 수신자가 연결이 되어있는 보장을 하지 않는다. → 비연결형

프레임 1~2개 정도 잠깐 안보여도 상관이 없는 실시간으로 화면을 보여줘야하는 게 중요한 상황에 사용 → 온라인 게임, 스트리밍에 적합