네트워크 심화

회선교환 방식 - 발신자와 수신자 사이에 데이터를 전송할 전용선을 미리 할당하고 둘을 연결한다. 1:1 교환만 가능

패킷교환 방식 - 패킷이라는 단위로 데이터를 잘게 나누어 전송. IP 주소라는 특정한 숫자값으로 표기하고 패킷단위로 데이터를 전송하게됨

 

IP / IP Packet

IP 패킷은 우체국 송장과 비슷하다

• 정확한 출발지와 목적지를 파악할 수 있다. 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷 전송 가능
• 비연결성 - 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성 - 중간에 있는 서버가 장애가 생겨 패킷이 소실 돼도 클라이언트는 이를 파악할 수 없음. 또한 전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하는데 패킷들은 중간에 서로 다른 노드를 통해 전달 될 수 있다. 이러면 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있다.

TCP / UDP

• TCP
  • IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜 존재
  • 네트워크 표준은 TCP/IP 4계층에 가깝다.
  • 연결 지향, 데이터 전달 보증, 순서 보장, 신뢰할 수 있는 프로토콜

• UDP
  • 기능 거의 없음
  • 비 연결지향, 데이터 전달 보증 X, 순서 보장 X, 단순하고 빠름, 신뢰성보단 연속성(스트리밍)

 

OSI 7계층

• 표준화를 통해 포트, 프로토콜의 호환 문제를 해결하고 네트워크 시스템에서 일어나는 일을 해당 계층 모델을 이용해 쉽게 설명 가능
• 네트워크 관리자가 문제가 발생 했을 때 범위를 좁혀 문제를 쉽게 파악할 수 있다.
• 1계층( 물리계층 ) - 물리적인 연결과 전기 신호를 변환 및 제어하는 계층
• 2계층 (데이터링크 계층) - 네트워크 기기 간의 데이터 전송 및 물리주소를 결정하는 계층 알아 볼 수 있는 데이터 형태로 처리함
• 3계층 (네트워크 계층) - 가장 복잡한 계층. 네트워크 간 데이터 라우팅 담당(최적의 경로를 선택하는 과정)
• 4계층 (전송 계층) - 컴퓨터간 신뢰성 있는 데이터를 주고받을 수 있도록 하는 서비스를 제공하는 계층 순서도 잡아줌
• 5계층 (세션 계층) - 세션 연결의 설정과 해제, 세션 메세지 전송 등의 기능을 수행하는 계층 (통신 방식에 대해 결정하는 계층)
• 6계층 (표현 계층) - 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층
• 7계층 (응용 계층) - 최종적으로 사용자와의 인터페이스를 제공하는 계층(사용자가 실행하는 응용 프로그램)
• 상위 계층에서 하위 계층으로 데이터를 전달할 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이를 헤더라 한다.
• 헤더를 붙여나가는 것을 캡슐화라고 한다. 데이터를 받는 쪽은 헤더를 하나씩 제거하는데 이를 역캡슐화라 한다.4

TCP / IP 4계층

• OSI 7계층 이론을 실용성에 기반을 두어서 실제 사용하는 현대 인터넷 표준
• 응용, 전송, 인터넷, 네트워크 접속 계층으로 이루어져 있다.
• 4계층(어플리케이션 계층, 응용계층) - OSI 계층의 세션,표현,응용 계층에 해당 TCP/UDP 기반의 응용 프로그램 구현할 때 사용(FTP, HTTP, SSH)
• 3계층 (전송 계층) - OSI 계층의 전송 계층. 통신 노드간의 연결 제어, 신뢰성 있는 데이터 전송 담당 (TCP/UDP)
• 2계층 (인터넷 계층) - OSI 계층의 네트워크 계층에 해당. 통신 노드간의 IP 패킷을 전송하는 기능 및 라우팅 담당. (IP, ARP, RARP)
• 1계층 (네트워크 인터페이스 계층) - OSI 계층의 물리, 데이터 링크 계층에 해당. 물리적인 주소로 MAC을 사용 (LAN, 패킷망)

HTTP

• 클라이언트 서버 구조
• 무상태 프로토콜(Stateless)
  • 서버 확장성이 높으나(무한한 서버 증설 가능) 클라이언트가 추가 데이터를 전송해야함
  • 여러 서버가 하나의 클라이언트 상대 가능
  • 로그인이 필요한 서비스라면 상태를 유지해야하기 때문에 쿠키, 서버세션, 토큰 등을 이용해 상태를 유지한다.
• 비연결성 (Connectionless)
  • 실제로 요청을 주고받을 떄만 연결 유지하고 응답을 주면 TCP/IP 연결을 끊는다.
  • 최소한의 자원으로 서버 유지 가능
  • 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우 비연결성의 특징은 효율적으로 작동
  • TCP/IP 연결을 새로 맺어야함
  • 웹 브라우저로 사이트를 요청하면 HTMP,JS,CSS 추가 이미지등 수많은 자원이 함께 다운로드 된다.
  • 자원을 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적이기 때문에 요즘은 지속 연결로 문제를 해결
  • 지속 연결로 모든 자원에 대한 응답이 돌아온 후에 연결을 종료

HTTP 표현 헤더

• 메세지 본문을 통해 표현 데이터 전달. - 데이터를 실어 나르는 부분을 페이로드(Payload)라한다.
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공, HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용
• Content-Type : 표현 데이터의 형식, Encoding: 압축방식, Language : 자연 언어, Length: 길이
• Transfer-Encoding - 전송 시 어떤 인코딩 방법을 사용할 것인가를 명시. 사용하는 경우 chunked의 방식으로 사용한다.
• chunked 방식의 인코딩은 많은 양의 데이터를 분할하기 때문에 전체 데이터의 크기를 알 수 없어 Content-Length 헤더와 함께 사용할 수 없다.

요청에서 사용되는 헤더

• From - 유저 에이전트의 이메일 정보. 주로 검색 엔진에서 사용
• Referer - 이전 웹 페이지 주소. 유입경로 수집 가능
• User-Agent - 유저 에이전트 어플리케이션 정보. 통계 정보. 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• Host - 요청한 호스트 정보(도메인) - 필수 헤더. 하나의 서버가(하나의 IP 주소에) 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
• Origin - 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄. 보낸 주소와 받는 주소가 다르면 CORS 에러 발생
• Authorization - 인증 토큰을 서버로 보낼 떄 사용하는 헤더. 토큰의 종류(Basic) + 실제 토큰 문자를 전송

응답에서 사용되는 헤더

• Server - 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
• Date - 메세지가 발생한 날짜와 시간
• Location - 페이지 리디렉션. (Location 헤더가 있으면 자동 이동)
• Allow - 허용 가능한 HTTP 메서드
• Retry-After - 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

콘텐츠 협상 헤더(요청시)

• Accept : 클라이언트가 선호하는 미디어 타입 전달 , -Charset : 문자 인코딩 , -Encoding : 압축 인코딩 , -Language : 자연 언어
• 0~1, 클수록 높은 우선순위. 생략하는 경우 1. 우선순위 지정할 수 있음

HTTP 헤더 - 캐시

• 캐시가 없을 때 - 데이터가 변경되지 않아도 계속 다운로드 받아야함, 느리고 비쌈, 로딩 느림, 느린 UX
• 캐시 : 데이터나 값을 미리 복사해 놓는 임시 장소. 데이터 미리 복사해 놓으면 빠른 속도 시간. 유효시간 설정 가능
  
  • 캐시 가능 시간동안 네트워크 사용하지 않아도 됨
  • 비싼 네트워크 사용량 줄일 수 있음
  • 로딩 속도 매우 빠름 , 빠른 UX
  • 유효 시간 초과할 경우 데이터 다시 조회 후 캐시 갱신, 다시 네트워크 다운로드 발생

캐시 검증 헤더

• 검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있다. 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함
• 캐시 유효시간 초과되도 If-Modified-Since 헤더를 이용해 조건부 요청할 수 있음.

검증 헤더와 조건부 요청

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 -> 304 Not Modified + 헤더 메타데이터만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터 갱신, 캐시에 저장되어 있는 데이터 재활용
• 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 1초 미만 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• ETag(Entity Tag) - If-None-Match
  • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠( ETag : "v1.1" , ETag : "124ebdfa012c12")
  • 데이터가 변경되면 이 이름을 바꾸어서 변경 ( ETag : "124ebdfa012c12" -> "13asg9x9ak2nmd") 다르면 받음
  • 캐시 제어 로직을 서버에서 완전히 관리

• Cache-Control : max-age - 캐시 유효시간
• Cache-Control : no-cache - 데이터는 캐시가능 항상 원서버에 검증하고 사용
• Cache-Control : no-stroe - 데이터에 민감한 정보가 있으므로 저장하면 안됨
• Expires : 캐시 만료일을 정확한 날짜로 지정 지금은 Cache-Control : max-age 권장 <--가 우선순위

프록시 캐시

• 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 카르켜 프록시, 그 중계 기능을 하는 서버를 프록시 서버라 한다.
• 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하고 프록시 캐시 서버의 캐시를 public 캐시라 한다.

• Cache-Control:public - 응답이 public 캐시에 저장됨
• Cache-Control:private - 응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본 값)
• Cache-Control:s-maxage - 프록시 캐시에만 적용되는 max-age
• Cache-Control: must-revalidate - 캐시 만료 후 최초 조회 시 원 서버에 검증해야 함, 원 서버 접근 실패시 504 오류
• Age: 60 (HTTP 헤더) - 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간
• no-cache : 원 서버 접근 못할 때 대체 데이터라도 보여줄 수 있음
• must-revalidate : 원 서버 접근 못할 때 무조건 504 에러