HTTP와 네트워크

yoon Y·2022년 4월 24일
0

네트워크

TCP/IP란 인터넷에 관련된 다양한 프로토콜의 집합

애플리케이션 계층

  • HTTP프로토콜 사용
  • 리퀘스트 요청 및 처리
  • DNS로 도메인명에서 IP주소로 변환해주는 역할

전송계층

  • TCP프로토콜 사용
  • 대용량의 데이터를 보내기 쉽게 작게 분해(패킷)하여 상대에게 보내고,
  • 정확하게 도착했는지 확인하는 역할(쓰리웨이 핸드셰이킹: 클-보냈음 -> 서-받았음 -> 클-ok완료)

네트워크 계층

  • IP프로토콜 사용
  • 패킷들을 운반시키는 역할
  • 여러 곳들을 경유
  • 최적의 경로를 결정

링크 계층

  • 데이터를 받는 하드웨어

통신의 과정

<클라이언트>
애플리케이션(http)  - http 요청 메세지 작성, 도메인을 ip로 변경
전송계층(tcp)      - http 요청 메세지 패킷으로 분해. 서버에게 전송
------------
<인터넷?>
네트워크 계층(ip)   - 여러 컴퓨터,네트워크 기기들을 경유하며 패킷 전달
------------
<서버>
링크 계층          - 서버 컴퓨터에 도착
전송계층(tcp)      - 패킷 조립
애플리케이션(http)  - http 요청 메세지를 보고 요청 처리

http의 버전

http1.0
TCP연결은 한 요청 단위임 연결이 되면 패킷들을 전송
그러나 요즘에는 한 웹페이지를 구성하기 위해 많은 리소스가 필요

http1.1
HTML에 연결된 많은 리소스를 요청할 때매다 연결하고 끊고하기 너무 번거롭고 느림. 그래서 http1.1에 한 연결에 여러 요청을 할 수 있는 지속 연결 기능과
여러 요청을 병행적으로 할 수 있는 파이프라인 기능, 데이터 압축/압축 해제 등의 기능이 추가되어 속도가 개선됨

http2.0
http1.1의 성능을 개선했다.
1.Multiplexed Streams
Pipelining의 개선 버전. Pipelining은 요청은 병행할 수있지만 응답은 요청 순서에 따라 받아야한다. Multiplexed Streams은 응답을 요청 순서에 상관없이 Stream으로 받기 때문에 HOL Blocking이 발생하지 않는다.
2.Stream Prioritization
리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결함(ex- img파일 보다 css가 더 먼저 도착해야함)
3.Server Push
서버는 클라이언트가 요청하지 않은 리소스를 사전에 푸쉬를 통해 전송할 수 있다. 예를 들면 클라이언트가 html문서를 요청하면 서버가 html에 담긴 리소스들까지 알아서 보내주기 때문에 클라이언트의 요청을 최소화할 수 있다.

전송 메세지 구성

데이터 전송 단위인 패킷에 요청/응답에 대한 메시지가 담겨있다

  • 시작라인 ( Request/response Line )
    • method/상태코드, uri, http버전
  • 헤더 ( Header )
    • 일반 헤더 - 요청 및 응답 메시지 모두에서 사용 가능한 일반 목적의(기본적인) 헤더 항목
    • request/response 헤더 - 클라이언트/서버에 대한 정보+요청/응답에 대한 정보
    • 엔티티 헤더 - Body에 담긴 데이터에 대한 정보
  • 본문 ( Body )
    • 데이터

헤더의 종류와 주요 필드

일반 헤더

  • cache-control: 캐시 동작 지정
  • connection: 클라이언트와 서버 간 연결에 대한 옵션 설정(close/keep-alive)
  • date: 메세지 생성 날짜

request 헤더

  • Host: 요청하는 호스트에 대한 호스트명 및 포트번호
  • User-Agent: 클라이언트 정보
  • Authorization: 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
  • Cookie: 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
  • Origin: 요청이 어느 주소에서 시작되었는지 나타낸다.
    요청을 보낸 주소와 응답의 주소가 다르면 CORS 에러가 발생한다.
  • Accept: 클라이언트 자신이 원하는 미디어 타입 및 우선순위.
  • Accept-Charset: 클라이언트 자신이 원하는 문자 집합
  • Accept-Encoding: 클라이언트 자신이 원하는 문자 인코딩 방식
  • Accept-Lenguage: 클라이언트 자신이 원하는 가능한 언어

response 헤더

  • Server: 서버 정보
  • Set-Cookie: 클라이언트에게 세션 쿠키 정보(사용자 인증 정보)를 전달
  • Allow: 해당 자원 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트
    때론, HTTP 메소드 OPTIONS에 대한 응답용 항목으로 사용된다.
  • Access-Control-Allow-Origin:
    요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생.
    서버에서 이 헤더에 허용하는 프론트 주소를 적어주어야 에러가 나지 않는다.
    *를 사용해 모든 주소를 허용할 수도 있다.

엔티티 헤더
body에 실린 Entity(콘텐츠, 본문, 리소스 등)에 대한 설명

  • Content-Type: 데이터의 미디어 타입 정보+인코딩 방식 지정
  • Content-Language:
  • Content-Encoding: 데이터 압축 방식
  • Content-Length: 데이터의 바이트 길이 또는 크기
  • Content-Location: 데이터의 실제 위치
  • Location: 리다이렉트 되어야 할 때 어느 곳으로 이동할지 명시

CORS

원래 보안상의 이유로 기본적으로 브라우저는 도메인이 다른 서버의 리소스를 받는 것을 제한한다.(SOP)
하지만 요즘에는 클라이언트에서 도메인이 다른 서버에서 제공하는 API를 사용하는 일이 많아졌다.
그렇기에 요청 도메인이 서버에 등록된 도메인이라면, 다른 도메인의 서버에서도 응답을 받을 수 있도록 해주는 정책인 cors가 등장했다.

브라우저에서 출처를 비교한다.

  • simple requests (단순 요청)
    • 조건이 매우 까다롭다.
  • preflighted request (사전 요청)
    • 실제 서버 요청 전에 가능한지 options요청으로 먼저 확인하는 것.
    • 단순 요청의 조건이 까다롭기 때문에 대부분 사전 요청으로 실행된다.
  1. 도메인이 다른 서버에 요청할 경우 헤더의 Origin속성의 나의 도메인도 같이 보내야한다.(브라우저가 자동으로 해줌)
  2. 서버에서도 해당 도메인이 허용된 것이라면, 응답값에 Access-Control-Allow-Origin에 해당 도메인을 같이 보내준다.
  3. 응답을 받은 브라우저는 Access-Control-Allow-Origin 헤더가 탭의 출처와 일치하는지 확인한다. Access-Control-Allow-Origin 값이 정확히 출처와 일치하거나, "*" 와일드 카드 연산자를 포함하는 경우 검사가 통과된다.

https://velog.io/@nichol/SOP-CORS
https://evan-moon.github.io/2020/05/21/about-cors/


브라우저 저장 공간

모두 도메인 단위이고, 브라우저 저장 공간이다.

쿠키

단점

  • 쿠키를 설정하면 이후 모든 웹 요청은 쿠키 정보를 포함하여 서버로 전송되기 때문에 트래픽 비용이 큽니다.
  • 쿠키는 개수와 용량의 제한이 있다.

장점

  • 만료일자를 지정할 수 있어 데이터 저장 기간을 설정할 수 있다.

Web Storage

장점

  • 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다.
    데이터를 선별해서 전송할 수 있기 때문에 네트워크 트래픽 비용을 줄여 준다.
  • 갯수의 제한이 없고, 쿠키에 비해 큰 용량을 가진다.

단점

  • 저장 기간을 설정할 수 없다.

Local

  • 직접 삭제하지 않는 한 영구 저장된다.

session

  • 세션 기간(탭이 열린동안) 내에서만 지속 가능하다
  • 탭마다 sessionStorage는 따로 배정되며 서로의 영역을 공유하지 않는다
profile
#프론트엔드

0개의 댓글