[코드 스테이츠] 105일차, "15주차 복습(2) - 네트워크'

---

[ 오늘의 TODO ]

1. 코드 스테이츠) 월~수 내용 복습
   // 네트워크 기본 개념
2. 팀 프로젝트) Workflow 작성
3. 생활) 물 1L 이상 마시기
4. 생활) 1시간 이상 걷기 
   // 드디어 걸었다 ㅠㅠㅠ

 

---

[ 오늘의 복습 ]

1. IP (인터넷 프로토콜)

 

코드 스테이츠 제공. TCP/IP 4 계층은 OSI 7 계층보다 먼저 개발됐고, 각 계층끼리의 일치 관계는 정확하지 않다.

1-1) IP와 IP Packet

 

\https://www.khanacademy.org/computing/computers-and-internet/xcae6f4a7ff015e7d:the-internet/xcae6f4a7ff015e7d:routing-with-redundancy/a/ip-packets

 

https://www.khanacademy.org/computing/computers-and-internet/xcae6f4a7ff015e7d:the-internet/xcae6f4a7ff015e7d:routing-with-redundancy/a/ip-packets

  IP 와 IP Packet 이란?

  IP 는 복잡한 인터넷 망 속에서 수많은 노드(서버 컴퓨터)를 거친 후 서버와 클라이언트가 통신할 수 있도록 만들기 위한 하나의 규칙이다. IP 주소를 컴퓨터에 부여하고 이 주소를 통해 통신한다. IP 는 지정한 IP 주소에 패킷(Packet) 이라는 통신 단위로 데이터를 전달한다. IP 패킷은 pack 과 bucket 이 합쳐진 단어로 전송할 데이터를 담은 택배 박스라고 생각하면 된다. IP 패킷은 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP 와 같은 정보가 포함돼 있다. 패킷 단위로 전송하면 노드들은 목적지 IP에 도착하기 위에 서로 데이터를 전달한다. 

  

  정확한 출발지와 목적지를 파악할 수 있다는 점에서 IP 프로토콜은 무결점인 것 같지만 두 가지의 단점이 존재한다

 

  1. 비연결성

  만약 패킷을 받을 대상이 없거나 서비스 불능 상태라면 클라이언트는 목적지 IP 주소만 알뿐이지 서버 상태를 파악할 방법이 없기에 패킷을 그대로 전달하게 된다. 

 

  2. 비신뢰성

  중간에 있는 서버가 데이터를 전달하다가 장애가 생겨서 패킷이 중간에 소실되더라도 클라이언트는 이 누락을 확인할 방법이 없다. 또, 전달하는 데이터의 용량이 클 경우 이를 패킷 단위로 나누어 데이터를 전달하게 되는데 이 패킷들은 같은 노드들을 타면서 가는 것이 아니라 중간에 다른 노드로 갈라질 수 있다. 이렇게 되면 클라이언트가 원하는 순서대로 서버에 패킷이 도착하지 못할 수 있다. 

 

 

TCP VS UDP

  네트워크 프로토콜 계층은 OSI 7 계층과 TCP/IP 4 계층으로 나눌 수 있다. IP 프로토콜보다 더 높은 계층에 TCP 프로토콜이 존재하기에 IP 프로토콜의 한계를 보완할 수 있다. 

 

  채팅 프로그램에서 메시지를 보낼 때를 가정해보자.

1. 프로그램이 "안녕?" 이라는 HTTP 메시지를 생성
2. Soket 라이브러리르 통해 전달 (Socket 이란 프로그램이 네트워크에 송수신할 수 있도록 네트워크 환경에 연결할 수 있도록 만들어진 연결부를 네트워크 Socket 이라고 한다) 
3. IP 패킷 생성 전에 메시지 데이터를 포함한 TCP 세그먼트를 형성한다
4. TCP/IP 패킷은 LAN 같은 물리 계층을 지나가기 위해 이더넷 프레임 워크에 포함돼 서버로 전송된다.

 

  TCP 세그먼트에는 IP 패킷에 담을 정보인 출발지 IP, 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보를 포함한다. 

 

  TCP (저송 제어 프로토콜) 의 특징은 다음과 같다

1. 연결 지향 - TCP 3 way handshake
   : TCP 는 장치들 사이 논리적 접속을 성립하기 위해 3way handshake 를 사용한다.
       a. 클라이언트가 서버에 접속을 요청하는 SYN(synchronize) 패킷을 먼저 보낸다
       b. 서버는 SYN 요청을 받고 수락한다는 ACK(acknowledgement), SYN 이 설정된 패킷을 발송한다. 
       c. 클라이언트가 다시 ACK 를 보낸다
       d. 연결이 성립한다.
   : 만약 서버가 꺼져 있다면 클라이언트가 SYN 을 보내고 서버로부터 응답이 없으므로 데이터를 보내지 않는다
2. 데이터 전달 보증
   : 데이터 전송이 성공적으로 이뤄지면 응답을 되돌려주기에 IP 의 비연결성을 보완한다.
3. 순서 보장
   : 패킷이 순서대로 도착하지 않으면 TCP 세그먼트에 있는 정보를 토대로 다시  패킷 전송을 요청할 수 있다.
4. 신뢰할 수 있는 프로토콜 (UDP 에 비해)

 

  UDP (사용자 데이터그램 프로토콜) 의 특징은 다음과 같다

1. 기능이 거의 없음
   : UDP 는 IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜이다.
   : 체크섬은 중복 검사의 한 형태로 오류 정정을 통해 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법을 의미한다. 
2. 비연결 지향
3. 데이터 전달을 보증하지 않고 순서도 보장하지 않는다
4. 그러나 단순하고 빠르다
5. 신뢰성보다는 연속성이 중요한 서비스(실시간 스트리밍)에 적합하다

  현재 사용하고 있는 HTTP3 은 UDP 기반이다.

 

 

  HTTP 

  HTTP의 특징은 다음과 같다. 

1. 클라이언트 서버 구조
   : 클라이언트가 서버에 요청 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이뤄져 있다
   
   
2. 무상태 프로토콜
   : HTTP에서는 서버가 클라이언트 상태를 보존하지 않는 무상태 프로토콜이다. 무상태이기에 서버 확장성이 높다. 하지만, 클라이언트가 추가 데이터를 전송해야한다는 점에서 단점이 있다. (쿠키 같은 거)
   
   : 무상태이기에 서버 확장성이 높은 이유는, 만약 상태가 존재한다면 서버를 바꿀 때 원래 어떤 상태였는지를 전달하는 과정이 오랜 시간 걸리겠지만 무상태라면 언제든 다른 서버로 바뀌어도 상관 없기 때문이다. 클라이언트가 급증하면 그만큼 서버를 많이 증설할 수 있다. 즉, 응답 서버를 쉽게 바꿀 수 있으므로 무한한 서버 증설이 가능하다
   
   : 물론, 다음과 같은 한계점은 존재한다. 모든 것을 무상태로 설계할 수 없는 경우도 존재한다. 로그인이 필요한 서비스라면 상태를 유지하기 때문에 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야만 한다. 
   
   
3. 비연결성 (HTTP 1.0) => 지속 연결(HTTP 2 버전 이상)
   : 비연결성을 갖는 HTTP 에서는 실제 요청을 주고 받을 때만 연결을 유지하고 응답을 주면 TCP/IP 연결을 끊는다. 최소한의 자원으로 서버에 연결할 수 있다는 장점이 존재한다.
   
   : 단점으로는 TCP/IP 연결을 새로 맺으면서 시간이 더 걸린다는 점. 웹 브라우저 사이트 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 수많은 이미지가 함께 다운로드 된다는 점이다.
   
   : 지금은 지속 연결 문제로 해결했다. 지속 연결을 한 후 각각의 자원을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다. 
   
   
4. HTTP 메시지
5. 단순함, 확장 가능

 

 

 

2. HTTP 헤더

  HTTP 메시지는 헤더와 바디로 구분할 수 있다. 바디에서는 데이터 메시지 본문을 통해 표현(representation) 데이터를 전달한다. 

 

2-1) 표현 헤더 

  표현은 요청이나 응답에서 전달할 실제 데이터를 의미한다. 표현 헤더는 표현 데이터를 해석할 정보를 제공한다. Content-Type, Content-Length 등이 해당한다. 작성 방법은 <field-name>: <field-value> 의 형식이다. 예를 들면 Content-type: text/html 과 같은 방식이다. 

 

  HTTP 전송에 필요한 모든 부가 정보들을 담는다. 예를 들면 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등이다. 

 

  Content-Type

  표현 데이터의 형식을 설명한다. 미디어 타입이나, 문자 인코딩 방식을 설명한다. 
  e.g "Text/html; charset=utf-8" , "application/json" , "Image/png"

  Content-Encoding

  표현 데이터를 압축하기 위해 사용한다. 데이터를 전달하는 곳에서 압축 후 인코딩 헤더에 추가한다. 데이터를 읽는 쪽에서는 인코딩 헤더의 정보를 사용하여 압축을 해제한다. 

  e.g "gzip", "deflate", "identity"

  Content-Language

  표현 데이터의 자연 언어를 표현한다. 
  e.g "ko", "en", "en-US"

  Content-Length 

  표현 데이터의 길이를 표현한다. 바이트 단위고 Transfer-Encoding 을 사용하면 Content-Length 를 사용할 수 없다. Transfer-Encoding 은 전송할 때 어떤 인코딩 방법을 사용할 것인가를 명시한다. 그러나 지금은 Content-Encoding 을 많이 사용하는 편이다. 

 

 

 

2-2) 요청에 사용되는 주요 헤더

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

  From

  유저 에이전트의 이메일 정보

  일반적으로 잘 사용하진 않고 검색 엔진에서 주로 사용한다

  Referer 

  현재 요청된 페이지 이전 웹 페이지의 주소

  A 페이지에서 B 페이지로 이동하는 경우 Referer: A 를 포함해서 요청을 한다. 

  유입 경로 수집이 가능해지고, referrer 의 오타지만 스펙으로 굳어졌다. 

  UserAgent

  클라이언트의 애플리케이션 정보(웹 브라우저 정보 등)

  어떤 종류의 브라우저에서 오류가 발생하는지를 파악할 수 있다.

  Host 

  요청한 호스트의 정보(즉, 도메인)

  헤더에서 필수로 사용

  하나의 서버가 여러 도메인을 처리해야할 때 호스트 정보를 명시하기 위해 사용하기도 하고

  하나의 IP 주소에 여러 도메인이 적용돼 있을 때, 호스트 정보를 명시하기 위해 사용한다.

  Host 정보가 없다면 IP 주소만을 가지고 어떤 도메인으로 요청이 왔는지 확인이 어렵고, 만약 가상 호스트를 통해 여러 도메인을 한 번에 처리하고 있는 경우 Host 를 통해 요청한 도메인을 찾을 수 있다.

  Origin

  서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타낸다

  여기서 요청을 보낸 주소와 받는 주소가 다를 경우 CORS 에러가 발생한다

  여기는 응답 헤더의 Access-Control-Allow-Origin 과 관련된다

  Authorization

  인증 토큰을 서버로 보낼 때 사용

  전송해줄 때, 토큰의 종류(Basic, Bearer) + 실제 토큰 문자

 

 

2-3) 응답에서 사용되는 주요 헤더 

  Server 

  요청을 처리하는 Origin 서버의 소프트 웨어 정보
  응답에서 사용 

  Date

  메세지가 발생한 날짜와 시간

  Location

  페이지 리디렉션

  웹 브라우저는 300번대 응답 결과에 Location 이 있을 경우, Location 위치로 자동 리다이렉트(Redirection)된다.

  201의경우, Location 값은 요청에 의해 생성된(Created) 리소스 URI 다.

  Allow

  허용가능한 HTTP 메소드

  405에서 응답에 포함한다. 받아들일 수 있는 HTTP 메소드를 나열

  Retry-After

  UserAgent 가 다음 요청을 하기까지 기다려야하는 시간

  503 에서 서비스가 언제부터 불능인지를 알려준다. 

 

2-4) 콘텐츠 협상 헤더

  클라이언트가 선호하는 표현 요청을 의마한다. 협상 헤더는 요청시에만 사용한다.

1. Accept : 클라이언트가 선호하는 미디어 타입
2. Accept-Charset : 클라이언트가 선호하는 문자 인코딩
3. Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
4. Accept-Language : 클라이언트가 선호하는 자연 언어
   > 만약 서버가 클라이언트에서 선호하는 자연 언어를 지원해주지 않을 경우 우선순위를 지정할 수 있다. 

 

 

 

3.  캐시

3-1) 캐시 기본 개념

  클라이언트가 이미지를 요청하고 서버가 해당 이미지에 대한 답을 줄 때, 이후에 같은 이미지를 요청하더라도 새로 다운을 받아야 한다. 이때 발생하는 문제점은 

1. 데이터가 변경 되지 않아도 동일한 데이터를 네트워크를 통해 계속해서 받아야 한다
2. 인터넷 네트워크는 느리고 비쌈.
3. 브라우저 로딩 속도가 느려짐
4. 용량이 클수록 비용은 더 커지고 로딩 속도도 느려진다.

  캐시란 컴퓨터 과학에서 데이터나 값을 미리 복사해놓는 임시 장소를 의미한다. 캐시는 캐시의 접근 시간에 비해 원래 데이터에 접근하는 시간이 오래 걸릴 경우나, 동일한 값임에도 재요청해야할 경우 시간을 절약하고 싶을 때 사용한다. 캐시 안에 미리 데이터를 복사해 놓으면 재요청할 필요 없이 빠르게 데이터에 접근할 수 있다. 브라우저에 케시에 저장할 때 cache-control 속성을 통해 유효 시간을 지정할 수 있다.  

 

  캐시가 존재하면 두 번째 요청부터는 캐시를 우선 조회하게 된다. 유효 시간이 아직 지나지 않을 경우 해당 캐시에서 데이터를 가져온다. 캐시를 사용했을 때 장점은 다음과 같다

1. 네트워크를 따로 사용하지 않으므로 비용이 준다
2. 브라우저 로딩 속도가 빨라진다

    만약 캐시의 유효 시간이 지나게 되면 다시 서버에 요청하여 동일한 데이터를 받아 온다. 그리고, 기존에 있던 캐시는 지우고 새로운 캐시로 업데이트 한다. 

 

 

3-2) 검증 헤더와 조건부 요청

  Last-Modified 와 If-Modified-Since

  캐시의 경우 유효 시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 업데이트 했다. 유효 기간이 지났지만 변경이 없어 해당 데이터를 계속 써도 되는 상황이라면 더 효율적으로 그 데이터를 사용할 수 있도록 검증 헤더를 사용할 수 있다. 검증 헤더는 Last-Midified 를 통해 캐시의 수정 시간을 알 수 있다. 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함시키고 응답 결과를 캐시에 저장할 대 데이터 최종 수정일도 저장된다. 서버의 해당 자료의 최종 수정일과 비교해 데이터가 수정되지 않았을 경우 응답 메시지에 이를 담아서 알려준다. 이때, HTTP body 에는 아무런 데이터도 없고 Status codes는 304(Not Modified)를 보낸다. 클라이언트가 해당 응답 요청을 받은 후 캐시를 갱신하고 다시 유효 시간이 갱신된다. 이 과정을 순서대로 정리하면 다음과 같다.

 

1. 처음 GET 요청을 보낸다
2. HTTP 헤더, HTTP 바디 모두에 내용이 담겨서 들어온다. Header 에는 Last-Modified 로 데이터가 마지막에 수정된 시간을 담는다. 
3. 브라우저에서 렌더링을 하고 캐시와 수정일 정보를 담는다.
4. 두번 째 GET 요청을 보낸다. 이 때는 담고 있던 수정일 정보를 If-Modified-Since 라는 헤더를 포함시켜서 보낸다. 
5. 서버측에서 If-Modified-Since 로 보낸 날짜 이후에 데이터가 수정돼 있는지를 검증한다
6. 만약 수정되지 않았다면 바디를 제외한 HTTP 헤더만을 전송한다
7. 브라우저 캐시에서 응답 결과를 재사용하고, 헤더 메타 데이터를 갱신한다.
8. 브라우저에서는 캐시에 담긴 데이터를 렌더링한다. 

  즉, 캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않으면 304 status code 와 헤더 메타 데이터만 응답하고 바디에는 아무런 정보가 담기지 않는다. 네트워크 다운로드가 발생했으나 바디에 용량이 적은 헤더만 전송되고 용량이 큰 바디에 정보가 담기지 않는 것만으로도 효율이 좋아진 것. 

 

  하지만, 1초 미만 단위로 캐시 조정이 불가능 하다는 점. 데이터 일치 여부 로직이 아닌 날짜 기반의 로직을 사용하기에 같은 데이터지만 재업로드를 한 경우는 추적할 수 없다는 점. 서버에서 별도의 캐시 로직을 관리하고 싶을 때는 유용하지 않다는 점에서 단점을 지닌다 

 

  ETag 와 If-None-Match

  서버에서 완전히 캐시를 컨트롤 하고 싶은 경우 ETag 를 사용할 수 있다. 캐시용 데이터에 고유한 버전의 이름을 달아둔다. 데이터가 변경되면 이 이름을 바꾸어서 변경한다. 단순하게 ETag 만 보내서 같으면 유지, 다르면 다시 받는 방식이다 작동 방식은 다음과 같다

 

1. 처음 GET 요청을 보낸다
2. 서버에서 캐시에 저장할 데이터에 ETag 헤더로 이름을 붙인다. 보통 해싱으로 암호화하는데, 여기서는 임시로 aaa 라는 이름으로 데이터를 생성했다고 하자. 그러면 이 ETag 헤더에 aaa 를 담고 데이터를 보낸다. 
3. 브라우저에서는 ETag: aaa 인 데이터를 받아 렌더링하고 데이터를 캐시에 저장한다.
4. 지정해준 유효 기간이 끝나 두 번째 GET 요청을 보낸다. 이때는 aaa 를 If-None-Match 라는 헤더에 담아서 보낸다
5. 데이터를 새로 업데이트 했다면 그 데이터의 ETag 는 우리가 갖고 있는 ETag 의 값과 다를 것이다. 그러나 만약 수정이 없다면 기존의 ETag 의 값과 동일하다. 이렇게 If-None-Match 에 담아 보낸 값과 서버에서 갖고 있는 데이터의 ETag 를 비교하여 수정됐는지;를 검증한다
6. 수정되지 않았다면 바디를 제외한 HTTP 헤더만을 전송한다. 마찬가지로 304 status code 를 전송한다. 
7. 브라우저 캐시에서 응답 결과를 재사용하고, 헤더 메타 데이터를 갱신한다
8. 브라우저에서는 캐시에 담긴 데이터를 렌더링한다. 

 

    캐시와 관련된 조건부 요청 헤더

1. Cache-Control : max-age 
   캐시 유효 시간. 초 단위로 지정한다
   
   
2. Cache-Control : no-cache
   데이터는 캐시해도 되지만 항상 Origin 서버에서 검증하고 사용한다
3. Cache-Control : no-store
   데이터에 민감한 정보가 있으므로 저장하면 안 된다는 의미다. 메모리에서 사용하고 최대한 빠르게 삭제한다. 
   
   
4. Expires: <날짜>
   캐시 만료일을 정확한 날짜로 지정한다. Cache-Control 사용을 더 권장하고, Cache-Control 과 같이 쓰이면 Expires 는 무시된다

  

 

3-3) 프록시 캐시

  프록시란, 클라이언트와 서버 사이에 대리로 통신해주는 것을 가리켜 프록시라 하고, 그 중계 기능을 하는 서버를 프록시 서버라고 한다. 우리가 유튜브를 볼 때 미국에서 올린 영상이나 다른 먼 나라의 영상을 가져올 때, 굉장히 빠른 속도로 데이터를 가져오는 것을 확인할 수 있다. 이걸 가능하게 만들어주는 것이 프록시 캐시 서버다. 프록시 서버에서 데이터를 연결해주고 이걸 캐시에 저장한다. 만약, 이전의 한국 유저가 이 미국 데이터를 열람하고 한국 프록시 서버에서 캐시로 그 데이터를 저장했다고 하면 한국의 다른 유저가 그 데이터를 열람하고자 할 때 한국 프록시 서버에서 캐시에 저장한 데이터를 보내준다. 이때, 프록시 서버에서 저장된 캐시를 Public 캐시라고 한다. (각 유저가 브라우저 환경에서 저장하는 캐시는 Private 캐시라고 한다)

 

  프록시 캐시와 관련된 헤더는 다음과 같다

1. Cache-Control : public
   응답이 Public 캐시에 저장해도 된다
   
   
2. Cache-Control: private
   응답이 해당 사용자만을 위한 것. private 캐시에 저장해야 한다. 따로 지정하지 않아도 기본값으로 지정된다.
   
   
3. Cache-Control: s-maxage
   프록시 캐시에만 적용되는 max-age
   
   
4. Age: 60(HTTP 헤더)
   오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간

 

  클라이언트가 캐시를 적용하지 않고 임의로 브라우저가 캐시를 적용할 경우, 특정페이지에서 캐시가 되면 안 되는 정보가 있으면 이를 무효화하기 위해 다음의 헤더들이 존재한다.

 

1. Cache-Control : no-cache
   데이터는 캐시해도 되지만 항상 origin 서버에서 검증하고 사용한다.
   
   
   
2. Cache-Control : no-store
   데이터에 민감한 정보가 있으므로 저장하면 안 된다. 메모리에서 사용하고 최대한 빠르게 삭제한다.
   
   
3. Cache-Control : must-revalidate
   캐시 만료 후에 최초 조회 시 origin 서버에서 검증한다
   origin 서버 적븐 실패 시 반드시 오류를 발생시킨다. status code 504 가 뜬다.
4. Cache-Control: no-cache, no-store, must-revalidate
   Pragma : no-cache
   확실하게 무효화 응답을 하고 싶다면 캐시 지시어를 모두 넣는다.
   
   
   

 

 

 

 

 

 

 

 

 

REFERENCE

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types

MIME 타입 - HTTP | MDN

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Type

Content-Type - HTTP | MDN

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Encoding

Content-Encoding - HTTP | MDN

 

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields