네트워크

네트워크, 처리량, 트래픽, 대역폭, RTT

  1. 네트워크의 정의
      • 네트워크란 노드와 링크가 서로 연결되어 있으며 리소스를 공유하는 집합이다.
        • 노드: 서버, 라우터, 스위치 등 네트워크 장치
        • 링크(엣지): 유선 또는 무선과 같은 연결매체
  1. 트래픽의 정의
      • 트래픽은 특정시점에 링크 내에 흐르는 데이터의 양이다.
      • 서버에 저장된 파일을 클라이언트가 다운로드시 발생되는 데이터의 누적량이다.
      • 단위는 bps(bits per second)이다. (초당 전송 또는 수신되는 비트)
      • 트래픽과 처리량의 차이
        • 트래픽이 많아졌다 = 흐르는 데이터가 많아졌다.
        • 처리량이 많아졌다 = 처리되는 트래픽이 많아졌다.
  1. 처리량의 정의
      • 처리량(throughput)은 링크 내에서 성공적으로 전달된 데이터의 양이다.
  1. 대역폭의 정의
      • 대역폭(bandwidth)는 주어진 시간동안 네트워크 연결을 통해 흐를 수 있는 최대 비트수를 뜻한다.
      • 대역폭은 곧 최대 처리가능 트래픽을 뜻한다.
  1. RTT(Round Trip Time)
      • RTT는 신호를 전송하고 해당 신호의 수신확인에 걸린 시간을 더한 값.
      • 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간.
      • 예를 들어 클라이언트가 서버에 어떤 요청을 하고 그 요청에 대한 응답을 받았을 때 요청과 응답 사이에 걸린 시간이다.

네트워크 토폴로지

  1. 네트워크 토폴로지란?
      • 네트워크 토폴로지란 노드와 링크가 어떻게 구성되어 있는지를 뜻한다.
  1. 종류
    1. 버스
        • 특징
          • 하나의 회선에 여러 개의 노드
          • 노드 추가, 삭제 쉬움
          • 설치비용 적음
        • 장점
          • 소규모 네트워크를 구축하기 쉬움
          • 한 노드에 장애가 발생해도 다른 노드에 영향이 없음.
        • 단점
          • 메인 링크에 많은 트래픽이 생기면 정체현상 발생 가능성 높음.
          • 메인 링크 망가지면 큰 일남.
    2. 스타
        • 특징
          • 중앙에 있는 노드를 기반으로 연결된 형태
          • 노드 추가, 삭제 쉬움
        • 장점
          • 중앙노드가 아닌 한 노드에 장애가 발생해도 다른 노드에 영향 없음.
          • 안정성이 높음. 중앙 노드가 아닌 곳에 장애가 발생해도 다른 노드로 전이되기 어려운 구조이기 때문. 다른 노드에 영향을 미치기 위해서는 무조건 중앙 노드를 거쳐야 하기 때문에 보통 이런 현상을 방지하기 위해 중앙 노드에 방지 장치를 해 둠.
          • 한 링크에 문제가 생겨도 다른 링크는 정상작동 함.
        • 단점
          • 중앙노드에서 장애나면 큰 일남.
    3. 트리
        • 특징
          • 자료구조의 트리 형태처럼 연결되어 있는 형태.
          • 노트 추가, 삭제가 버스, 스타보다는 어려움.
          • 버스와 스타의 하이브리드 형태.
        • 장점
          • 노드 확장이 용이(주로 리프노드로 확장함)
          • 리프노드의 에러는 다른 부분에 영향을 끼치지 않음.
        • 단점
          • 특정 노드에 트래픽 집중시 하위노드에 영향을 끼침.
          • 루트노드에 문제 생기면 전체 네트워크에 문제 생김.
        • 특징
          • 고리형태
          • 노드 추가, 삭제가 쉬움
        • 장점
          • 노드 수가 많아져도 데이터 손실이 없음. 토큰 기반으로 연속적으로 노드를 거치며 권한 여부를 따지고 권한이 없는 노드는 데이터를 받지 않음.
        • 단점
          • 링크 또는 노드가 하나만 문제가 생겨도 전체 네트워크에 문제가 생김.
          • 토큰이 없는 노드는 통신에 참여를 못하며 데이터 공유가 안됨.
    4. 메시
        • 특징
          • 그물망 형태
          • 노드 추가, 삭제 가장 어려움.
          • Full 메시 토폴로지의 경우 n * (n-1) / 2의 회선이 필요함.
        • 장점
          • 안정성이 높음. 한 노드에 장애가 생겨도 다른 노드에 영향을 끼치지 않음.
          • 트래픽 분산이 용이.
        • 단점
          • 회선이 비효율적으로 많아져서 구축 비용이 비싸다.

캐스트 종류

  1. 유니캐스트
      • 1:1 통신
      • HTTP 통신이 대표적이다.
  1. 멀티캐스트
      • 1 : N 통신이다.
      • 1 : N 이지만 연결된 모든 노드에 데이터를 전달하는 것이 아니라 특정 그룹에만 데이터를 전달한다.
  1. 브로드캐스트
      • 1 : N 통신이다.
      • 연결되어 있는 모든 노드에 데이터를 전달한다.
 

LAN, MAN, WAN

  1. LAN
      • Local Area Network, 근거리 통신망
      • 집이나 사무실 등 소규모 네트워크의 형태.
      • 하나의 논리적 주소인 IP를 기반으로 여러 개의 물리적 주소인 MAC 주소로 구별하는 네트워크이다.
      • 공인 아이피를 하나 받아서 NAT 라우터를 통해 private ip를 할당받아 사용하는 구조가 보통이다.
      • 집에서 쓰는 공유기에 pc, ps4, 아이폰, mac 다 연결해서 인터넷을 사용하는 구조가 LAN이다.
  1. MAN
      • Metropolitan Area Network, 대도시 통신망
      • 2개 이상의 LAN이 연결되어 구성된다.
      • 라우터, 브리지 등으로 연결된다.
  1. WAN
      • Wide Area Network, 광역 통신망
      • 국가와 국가와의 통신망을 뜻한다. 인터넷이라고도 한다.
      • 수 많은 라우터를 거쳐 다른 국가와도 연결되는 범위이다.

TCP/IP 4계층

  1. 정의
      • 인터넷 상에서 데이터를 주고받을 때 쓰는 독립적인 프로토콜의 집합.
      • TCP(Transmission Control Protocol) / IP(Internet Protocol)
      • Application / Transport / Internet / Network Access 계층으로 4계층이다
        • Application 계층
          • HTTP, SMTP, SSH, FTP가 대표적.
          • 웹 서비스, 이메일 등 서비스를 실질적으로 사람들에게 제공하는 층.
        • Transport 계층
          • TCP, UDP가 대표적
          • 애플리케이션 계층에서 받은 메시지를 기반으로 세그먼트 또는 데이터그램으로 데이터를 쪼개고 데이터가 오류없이 순서대로 전달되도록 도움을 주는 층
        • network 계층 (Internet)
          • IP, ICMP, ARP가 대표적.
          • 한 노드에서 다른 노드로 전송 계층에서 받은 세그먼트 또는 데이터그램을 패킷화하여 목적지로 전송하는 역할.
        • link 계층 (Network Access)
          • 전선, 광섬유, 무선 등으로 데이터가 네트워크를 통해 물리적으로 전송되는 방식.
  1. 캡슐화와 비캡슐화
      • 캡슐화란 송신자가 수신자에게 데이터를 보낼 때 데이터가 각 계층을 지나며 각 계층의 특징들이 담긴 헤더들이 붙여지는 과정.
      • 전송 계층은 TCP 헤더, 네트워크 계층은 IP 주소 헤더를 추가하는 식.
      • 비캡슐화란 이 과정의 역이다. 수신자 측에서는 이렇게 캡슐화된 데이터를 역순으로 제거하면서 애플리케이션 계층까지 도달하는 과정.
  1. PDU
      • Protocol Data Unit
      • TCP/IP 4계층을 기반으로 설명했을 때 각 계층의 데이터 단위
        • 애플리케이션 계층: 메세지
        • 전송 계층: 세그먼트(TCP), 데이터그램(UDP)
          • 적절한 크기로 쪼갠 조각, 세그먼트 데이터그램은 형식에 따라 이름만 다를 뿐 같은 의미
        • 인터넷 계층: 패킷
          • 세그먼트에 SP와 DP가 포함된 IP 헤더가 붙은 형태의 조각
        • 링크 계층: 프레임(데이터 링크 계층), 비트(물리 계층)
          • 프레임: MAC 주소 헤더와 CRC/체크섬 트레일러가 붙은 조각
  1. CRC/체크섬 트레일러
      • 데이터의 오류감지를 위한 수학적 함수가 적용된 값들이 있는 필드.
      • 링크의 오류로 인해 데이터 손상을 감지하는 역할.
      • 데이터무결성을 체크할 수 있도록 해주는 방법.
        • CRC: CRC-1, CRC-16 등의 알고리즘으로 나온 값을 통해 데이터 전송오류감지를 수행한다.
        • 체크섬: MD5, SHA-256 등의 알고리즘으로 나온 값을 통해 데이터 무결성을 방지
  1. OSI 7계층
      • TCP/IP 4계층은 OSI 7계층으로 설명하기도 한다.
      • OSI 7계층에서는 애플리케이션 레이어를 세 개로 쪼개고 링크 계층을 데이터링크 계층, 물리 계층으로 한 번 더 쪼개서 표현한다.
        • Application Layer, Presentation Layer, Session Layer
        • Transport Layer
        • Network Layer
        • Data-Link Layer, Physical Layer

MTU, MSS, PMTUD

  1. MTU
      • Maximum Transmission Unit
      • 네트워크에 연결된 장치가 받아들일 수 있는 최대 데이터 패킷의 크기
      • MTU를 기준으로 데이터는 쪼개져서 패킷화 된다
      • 어떤 라우터나 장치의 MTU를 초과하는 경우에는 패킷을 분할할 수 없어서 아예 전달을 하지 않을수도 있다.
      • 일반적으로 1500바이트
  1. MSS
      • Maximum Segment Size
      • MTU는 IP헤더와 TCP 헤더의 크기까지 합치지만 MSS는 데이터의 크기(payload)만을 가리킨다.
      • 일반적으로 1460바이트
  1. PMTUD
      • Path MTU Discovery
      • 수신자와 송신자의 경로 상에서 장치가 패킷을 누락한 경우 테스트 패킷의 크기를 낮추면서 MTU에 맞게끔 반복해서 보내는 과정.

애플리케이션 계층

  1. 정의
      • HTTP, SMTP, SSH, FTP가 대표적이다. 웹 서비스, 이메일 등 서비스를 실질적으로 사람들에게 제공하는 층이다.
  1. HTTP
      • Hypertext Transfer Protocol
      • 서버와 브라우저 간에 데이터를 주고받기 위해 설계된 프로토콜.
      • 지금은 서버와 서버 간의 통신할 때도 많이 이용한다.
      • 특징
        • HTTP는 헤더를 통한 확장이 쉽다.
        • HTTP는 stateless하다.
  1. SSH
      • Secure Shell Protocol
      • 네트워크 서비스를 안전하게 운영하기 위한 암호화 프로토콜
  1. FTP
      • File Transfer Protocol
      • 노드와 노드 간의 파일을 전송하는데 사용되는 프로토콜
      • 현재는 암호화를 추가하여 FTPS, SFTP로 대체되고 있다.
  1. SMTP
      • Simple Mail Transfer Protocol
      • 인터넷을 통해 메일을 보낼 때 사용되는 프로토콜
      • JS의 경우에는 NodeMailer라는 라이브러리를 보편적으로 이용함.
      • Java는 Javax.mail를 사용하는 방법이 있다.

전송 계층

  1. 정의
      • TCP, UDP가 대표적이며 애플리케이션계층에서 받은 메시지를 기반으로 세그먼트 또는 데이터그램으로 데이터를 쪼개고 데이터가 오류없이 순서대로 전달되록 도움을 주는 층이다.
  1. TCP
      • 가상회선 패킷 교환 방식
      • 회선을 따라 순서대로 쪼개진 패킷이 전달 됨.
      • 오류검사 메커니즘
        • 재전송: 시간 초과(timeout) 기간이 지나면 서버는 전달되지 않은 데이터에 대해 재전송을 시도한다.
        • 체크섬: 체크섬을 통해 무결성을 평가한다. 송신된 데이터와 수신된 데이터의 체크섬 값을 비교해서 올바르게 왔는지 확인.
      • 헤더
        • 20 ~ 60 바이트로 가변적
      • 연결보장
        • 3웨이 핸드세이크로 연결을 맺고 **4웨이 핸드셰이크로 연결을 해제하는 작업이 필요함.
      • 브로드캐스트
        • 브로드캐스트 지원 안됨.
  1. UDP
      • 데이터그램 패킷 교환 방식
      • 쪼개진 패킷이 순서가 보장되지 않게 전달 됨.
      • 오류검사 메커니즘
        • 체크섬만 지원
      • 헤더
        • 8바이트로 고정
      • 연결보장
        • 연결이 보장되지 않고 데이터를 그냥 보내기만 함. 연결을 유지하고 해제하는 데 드는 비용이 없어서 속도가 빠름
      • 브로드캐스트
        • 지원 됨.
  • 3웨이 핸드쉐이크 - TCP 연결 과정
  1. SYN 단계
      • 클라이언트는 서버에 클라이언트의 ISN을 담아 SYN을 보냄.
  1. SYN + ACK 단계
      • 서버는 클라이언트의 SYN(Synchronization, 연결 요청 플래그)을 수신하고 서버의 ISN을 보낸다.
        • ISN: TCP 기반 데이터 통신에서 각각의 새 연결에 할당된 고유한 32비트 시퀀스 번호. 연결의 고유성을 부여하기 위함.
      • 서버에서 클라이언트로 승인번호를 보낼 때 클라이언트 ISN + 1을 보낸다.
  1. ACK 단계
      • 클라이언트는 서버의 ISN + 1한 값인 승인번호를 담아 ACK(Acknowledgement, 응답 플래그)를 서버에 보낸다.
  1. 클라이언트와 서버의 상태
      • 클라이언트
        • closed, syn-sent, established 순서로 진행
      • 서버
        • closed, listen, syn-received, established 순서로 진행
  • * 4웨이 핸드셰이크 - TCP 연결 해제 과정
  1. 클라이언트가 연결을 닫으려고 할 때 FIN으로 설정된 세그먼트를 보낸다. 이후 클라이언트는 FIN_WAIT_1 상태가 되고 서버의 응답을 기다린다.
  1. 서버는 클라이언트로 ACK라는 승인 세그먼트를 보내고 CLOSE_WAIT 상태에 들어간다. 클라이언트가 세그먼트를 받으면 FIN_WAIT_2 상태에 들어간다.
  1. 서버는 LAST_ACK 상태가 되고 일정 시간 이후에 클라이언트에 FIN이라는 세그먼트를 보낸다.
  1. 클라이언트는 ***TIME_WAIT 상태가 되고 다시 서버로 ACK를 보내서 서버는 CLOSED 상태가 된다. 이후 클라이언트는 TIME_WAIT으로 설정된 시간 동안 대기한 후 CLOSED 상태가 된다.
  • ** TIME_WAIT
  • 지연 패킷 등이 발생했을 떄 데이터 무결성을 보장하기 위해 패킷을 기다리는 시간이다. 2 * MSL(Maximum Segment Liftetime, 최대 패킷 수명) 동안 기다린다

라우팅

  1. 정의
      • 라우팅은 네트워크에서 데이터를 보낼 때 최적의 경로를 선택하는 과정이다.
      • 라우터가 이 과정을 수행한다.
  1. 라우터
      • 네트워크 사이에서 데이터를 전달하는 장치.
      • 보통 둘 이상의 서로 다른 네트워크에 연결된다.
      • 데이터를 목적지로 보낼 때 최적의 경로를 결정하고 경로가 결정되면 해당 경로로 데이터를 넘겨주는 일을 수행한다.
      • 라우터는 라우팅테이블을 기반으로 데이터를 다음 목적지에 전달한다.
  1. 라우팅 테이블
      • 라우팅 테이블은 IP 주소를 기반으로 라우터의 위치를 저장한 테이블 또는 DB이다.
      • 다양한 네트워크에 대한 정보와 해당 네트워크에 연결하는 방법이 포함되어 있다.
      • 라우팅 테이블의 구성요소
        • 네트워크 대상(Network Destination): 목적지 네트워크의 IP 주소
        • 서브넷 마스크: 대상 주소를 설명할 때 쓰이는 값.
        • 게이트웨이: 장치와 연결되어 있는 홉, 패킷이 전달되는 다음 IP 주소(외부 네트워크와 연결된 장치). 목적지가 로컬 네트워크인 경우에는 connected라고 표기된다. 외부 네트워크라면 해당 네트워크의 게이트웨이 주소를 가리킨다.
        • 인터페이스: 게이트웨이로 가기 위해 거치는 장치
        • 메트릭: 우선순위. 패킷 전송을 위해 최적의 경로가 선택되도록 참고하는 값. 동일 라우팅테이블 요소가 2개 있는 경우 메트릭이 낮은 요소가 선택됨. 메트릭은 일반적으로 홉 수(hop count)가 들어가며 지연시간, 처리량 등 또한 들어갈 수 있다.
          • 홉: 네트워크에서 출발지와 목적지 사이에 위치한 장치를 의미한다. 홉 카운트는 데이터가 출발지와 목적지 사이에서 통과해야 하는 홉의 개수를 의미한다.

IP주소, MAC주소, ARP, RARP

  1. IP 주소
      • 논리적 주소로 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해 사용하는 주소이다.
      • IP주소는 논리적 주소이고 IP주소 아래 MAC 주소가 물리적 주소이다.
  1. MAC 주소
      • MAC(Media Access Control Address) 주소는 네트워크 인터페이스에 할당된 고유 식별자이며 보통 장치의 NIC에 할당된다.
      • 48비트로 이루어져 있고 24비트의 OUI, 24비트의 UAA로 이루어져 있다.
        • OUI: IEEE에서 할당한 제조사 코드
        • UAA: 제조사에서 구별되는 코드
      • MAC 주소는 유일하지 않을수도 있다. 실수로든 의도적으로든 UAA를 중복되게 만들 수 있기 대문이다.
  1. ARP, RARP
      • 논리적 주소인 IP 주소를 물리적 주소인 MAC 주소로 변환하는 과정이 ARP이다.
      • 이 과정의 반대는 RARP이다.
      • ARP의 과정
        • 해당 IP주소에 맞는 MAC 주소를 찾기 위해 해당 데이터를 브로드캐스팅을 통해 연결된 네트워크의 모든 장치에게 보낸다.
        • 맞는 장치가 있다면 해당 장치는 데이터를 보낸 장치에게 유니캐스트로 응답을 전달하여 MAC 주소를 보낸다.

IPv4, IPv6

  1. IPv4
      • IPv4는 32비트로 표현되는 주소체계이다.
      • 2^32 개의 주소를 표현할 수 있다.
      • 8비트(1옥텟) 단위로 점을 찍어 4개로 구분해서 표현한다.
      • 보통 8비트를 10진수로 표현한다.
      • 헤더가 가변 길이이다.
  1. IPv6
      • 128비트로 표현되는 주소체계이다.
      • 2^128 개의 주소를 표현할 수 있다.
      • 16비트씩 8개로 구분하고 16비트는 16진수로 변환되어 콜론으로 구분하여 표시한다.
      • 앞의 연속되는 0은 생략될 수 있다.
      • 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 와 같은 형태이다.
      • 여기서 앞의 64비트는 네트워크 주소를 뜻하고 뒤의 64비트는 인터페이스 주소를 뜻한다.
      • IPSec이 내장되어 있다.
        • IPSec은 데이터 패킷을 암호화하는 보안 네트워크 프로토콜 제품군이다.
      • IPv4에 비해 헤더 포맷이 단순하다.
      • IPv4에는 체크섬이 있지만 IPv6는 체크섬이 있다.
        • IPv6에서는 상위 프로토콜인 TCP, UDP 헤더에 체크섬이 있기 때문에 효율성을 위해 체크섬필드를 없앴다.
      • 헤더가 40바이트로 고정길이다.

클래스풀

  1. 정의
      • 클래스풀(Classful IP Addressing)
      • 네트워크 주소를 매기고 그에 따라 네트워크의 크기를 다르게 구분하여 클래스를 할당하는 주소체계
      • 구분자(1, 2, 3옥텟)를 서브넷마스크라고 부른다.
  1. 클래스 A
      • 맨 앞의 1옥텟이 NET ID이다.
      • 이진수로 봤을 때 0으로 시작한다.
      • 뒤쪽의 3옥텟이 호스트 ID이다.
      • 따라서 한 네트워크당 2^24 - 2인 약 1600만개의 호스트 ID를 갖는다.
      • 네트워크 주소 범위는 1 ~ 126 으로 시작한다.
  1. 클래스 B
      • 앞의 2옥텟까지 NET ID이다.
      • 2진수로봤을때 10으로 시작한다.
      • 따라서 2^16 - 2 의 약 6만 5천개의 호스트 ID를 갖는다.
      • 네트워크 주소 범위는 128 ~ 191로 시작한다.
  1. 클래스 C
      • 앞의 3옥텟까지 NET ID
      • 2진수로 봤을 때 110으로 시작한다.
      • 2^8 - 2 = 한 네트워크당 254개의 호스트 ID를 갖는다.
      • 네트워크 주소 점위는 192 ~ 223으로 시작한다.
  1. 문제점
      • 작은 네트워크를 필요로 하는 경우에는 낭비가 발생할 가능성이 큼.
  • 호스트 ID를 계산할 때 2개를 빼는 이유는 맨 앞자리는 네트워크 주소로 사용하고 맨 마지막 주소는 브로드캐스팅 주소로 쓰기 때문에 -2를 한다.

클래스리스

클래스풀의 단점을 해결하기 위해 등장함.
클래스로 나누는 것이 아니라 서브넷마스크를 중심으로 어디까지가 네트워크 주소고 어디까지가 호스트주소인지를 나눈다.
CIDR(Classless Inter-Domain Routing) 표기방식을 사용하여 네트워크 주소를 표시한다. (192.168.1.0/24 와 같은 형태)
클래스풀보다 유연하게 네트워크를 할당하고 주소 낭비를 줄일 수 있다.
  • 서브네팅: 네트워크를 나눈다.
  • 서브넷: 서브네트워크, 쪼개진 네트워크
  • 서브넷마스크: 서브네트워크를 위한 비트마스크
    • 네트워크주소 부분만 모두 1, 호스트주소부분은 모두 0
    • 아이피주소값과 서브넷마스크를 AND 연산해주면 네트워크 주소를 알 수 있다.
notion image
notion image

공인 IP, 사설 IP, NAT

IP주소는 항상 부족한 상태이다. 이를 해결하기 위해 공인 IP, 사설 IP로 나누고 중간에 NAT라는 기술을 통해 해결한다.
  1. NAT
      • Network Address Translation
      • 패킷이 트래픽 라우팅 장치를 통해 전송되는 동안 패킷의 IP주소를 변경, IP 주소를 다른 IP 주소로 매핑하는 방법.
      • 내부 네트워크 IP가 노출되지 않는다.
  1. 공유기와 NAT
      • 실생활에서 인터넷 회선 하나를 개통하고 보통 공유기를 써서 wifi를 만드는 데 이 때 여러 대의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하게 된다.
      • 약속된 사설 IP 대역
        • 10.0.0.0 ~ 10.255.255.255
        • 172.16.0.0 ~ 172.31.255.255
        • 192.168.0.0 ~ 192.168.255.255
      • 공유기는 이 사설 IP를 공인 IP로 변환하여 인터넷과 통신할 수 있게 해주고 이 방식이 NAT이다.

HTTP 헤더

  1. 정의
      • 사용자가 HTTP요청을 하게 되면 헤더와 바디를 주고 받는다.
      • 바디는 본문이고 보통 JSON, html, image 등이 담긴다.
      • 헤더는 바디를 설명하는 정보를 포함하여 여러 정보가 담긴다.
      • 헤더는 key - value 형태로 설정된다.
      • HTTP 요청을 할 때 3가지의 헤더 - 일반헤더, 요청헤더, 응답헤더가 자동으로 생성된다.
      • 서버에서 설정하는 헤더는 응답헤더, 클라이언트에서 설정한 헤더는 요청헤더이다.
  1. 일반헤더
      • 요청 URL, 요청 메서드, 자원 요청시 해당 자원의 출처를 나타내는 URL의 노출여부를 정하는 보안정도가 설정되어 있는 Referrer Policy 등이 들어간다.
  1. 요청헤더
      • 요청 헤더는 클라이언트가 서버에 요청할 떄 클라이언트가 설정하거나 자동으로 생성하는 헤더
      • 요청 메서드, 클라이언트 OS, 브라우저 정보 등이 담긴다.
  1. 응답헤더
      • 서버가 클라이언트에 응답을 보낼 때 설정 또는 자동 설정되는 헤더
      • 응답 헤더는 서버의 소프트웨어 정보(nginx 등) 등이 담긴다

HTTP/1.0, HTTP/1.1의 차이

  1. HTTP/1.0
      • 수명이 짧은 연결.
      • 각 HTTP 요청당 TCP 핸드셰이크가 발생된다.
      • 기본적으로 한 연결 당 하나의 요청만 처리하도록 설계되었다.
      • 한 번 연결할 때마다 TCP 연결을 해야 해서 RTT가 늘어나는 단점이 있다.
  1. HTTP/1.1
      • keep-alive default
        • 매번 데이터를 요청할 때마다 TCP 연결을 하는 것이 아니라 한 번 해놓고 계속해서 데이터를 받을 수 있게 변경됨.
      • keep-alive header
        • TCP 연결을 유지하는 것을 알려주는 헤더로 연결유지시간인 timeout과 최대 요청수를 정할 수 있다.
      • 호스트 헤더
        • 1.0은 서버가 하나의 호스트만 가진다고 가정하기 때문에 헤더에 호스트를 포함하지 않는다. 이 때문에 1.0은 하나의 IP에 하나의 호스트만 가질 수 있다.
        • 하지만 서버는 여러 개의 호스트를 가질 수 있기 대문에 1.1에서는 헤더에 특정 호스트를 포함할 수 있게 변경되었고 항상 호스트를 포함해서 요청하도록 변경되었음.
      • 대역폭 최적화
        • 1.0의 경우 어떤 파일을 다운로드 받다 연결이 끊기면 재개가 불가능했다.
        • 1.1에서는 Range : bytes = xxxx- 라는 헤더를 추가해서 다운로드 재개가 가능해졌다.
  1. 요청을 줄이기 위한 기술
      • 1.1로 버전업이 되었음에도 서버에 요청할 때마다 RTT는 계속해서 증가하기 때문에 요청 자체를 줄이기 위한 기술들이 탄생했다.
      • 이미지 스프라이트
        • 수많은 이미지를 하나의 이미지로 만들어 하나의 이미지만 다운받아놓고 이를 통해 여러 이미지를 다운받는 듯한 효과를 내는 것이다.
      • 코드압축
        • 코드를 크대로 배포하는 것이 아니라 압축하여 배포한다.
      • 이미지 base64 인코딩
        • 이미지 파일을 이미지 요청을 통해 받는 것이 아니라 base64로 인코딩된 문자열을 가지고 이미지를 로드해서 이미지 요청을 없앤다. 다만 원본 이미지 크기보다 약 37% 크기가 커지는 단점이 있다.
  1. HTTP/1.1의 고질적인 문제 : HOL
      • HOL(Head Of Line Blocking)
        • 네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능저하 현상

HTTP/2, HTTP/3의 차이

  1. HTTP/2
      • 구글에서 HTTP/1.1의 한계를 극복하기 위해 SPDY 프로토콜을 개발함.
      • 2015년에 SPDY를 기반으로 HTTP/2를 만들었다.
      • 바이너리 포맷 계층
        • 애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가한다.
        • HTTP1.0은 일반 텍스트 메시지를 전송하고 줄바꿈으로 데이터를 나눴지만 HTTP/2.0은 바이너리 데이터로 변경됨. 더 작은 메세지가 '프레임'으로 캡슐화 되어서 전송됨.
        • h2, h2c
          • h2c는 TLS를 사용하지 않고 TCP 연결 위에서 직접 HTTP/2를 사용하는 방식이다.
          • 개발 환경에서의 디버깅 또는 로컬 테스트를 위해 암호화된 연결을 설정할 필요가 없기 때문에 편리하게 테스트에 이용할 수 있다는 장점, 암호화와 관련된 오버헤드가 없다는 장점이 있다.
          • h2는 tls가 장착된 http2이다. 브라우저에서는 HTTPS가 없는 HTTP2는 지원하지 않기 때문에 브라우저에서는 h2만 허용된다.
      • 멀티플렉싱
        • 단일 TCP 연결의 여러 스트림에서 여러 HTTP 요청과 응답을 '비동기적'으로 보낼 수 있다. 이 방식을 통해 HOL을 해결한다.
        • HTTP1.1에서는 병렬요청을 하려면 다중 TCP 연결을 통해서 해야 하고 일반적으로는 TCP 연결 하나당 병렬요청은 불가능 했다.
        • 위의 문제를 해결하는 방법으로 HTTP/2.0에서는 리소스를 작은 프레임으로 나누고 이를 스트림으로 프레임을 전달한다. 각각의 프레임은 스트림 ID, 해당 청크의 크기를 나타내는 프레임이 추가되었기 때문에 작게 나눠서 다운로드가 되더라도 결과적으로 응답 데이터에서는 올바른 순서로 재조립할 수 있게 된다.
      • 서버푸시
        • 서버가 리소스를 클라이언트에 푸시를 할 수 있다. 요청된 html파일과 함께 다른 개체를 별도로 보낼 수 있다. 만약 요청한 html에 css가 포함되어 있다면 별도 요청없이 css를 같이 보낼 수 있다.
      • 헤더압축
        • HTTP/1.1에는 무거운 헤더가 있었지만 2.0에서는 허프만 인코딩 방법으로 압축시킨다. 똑같은 서버에서 2개의 이미지를 준다고 했을 때 중복되는 헤더는 제외한 채로 보내고 해당 공통 필드로 헤더를 재구성하며 중복되지 않은 헤더 값은 허프만 인코딩 압축 방법으로 압축해서 전송한다.
        • 허프만 인코딩: 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용해 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 전체 데이터 표현에 필요한 비트양을 줄이는 알고리즘입니다.
      • 우선순위
        • 서버에서 원하는 순서대로 우선순위를 정해 리소스를 전달할 수 있다.
  1. HTTP/3
      • HTTP/2는 여전히 TCP를 사용하기 때문에 초기 연결에 대한 RTT로 인해 지연시간이 생기는 문제점이 있었는데 이를 해결한 게 HTTP/3이다.
      • TLS1.2, TCP 계층 대신 QUIC(Quick UDP Internet Connections)라는 계층 위에서 돌아가고 UDP 기반으로 동작한다.
      • 멀티플렉싱 또한 가능하고 초기 연결 설정시 지연시간 감소라는 특성이 있다.
      • HTTP/2 경우 3 - RTT가 필요했다면 QUIC는 1 - RTT만 필요하다는 장점이 있다.
      • HTTP/2의 경우 클라이언트와 서버 간의 연결을 맺어 세션을 만드는 데 필요한 핸드셰이크, 암호화 통신을 구축하기 위한 TLS 핸드셰이크가 각각 필요했으나 HTTP/3는 TLS로 암호화통신을 구축할 때의 단 한 번의 핸드셰이크를 활용해 클라이언트와 서버 간의 연결, 암호화 통신 모두 다 구축할 수 있다. 이를 통해 1 - RTT만에 모든 연결을 만들 수 있다.
      • 전송된 패킷이 손실 되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷손실률을 자랑하는 순방향 오류 수정 메커니즘(FEC, Forward Error Correction)이라는 특징을 가진다.

HTTPS와 TLS - 암호화, 핸드셰이크

암호화는 승인된 당사자만 정보를 이해할 수 있도록 데이터를 스크램블한 방법이다. 이를 복화화하려면 송신자와 수신자가 서로 동의한 가 필요하다.
  1. 스크램블
      • 각 단어나 문자를 패턴에 따라 암호화하는 것이 아니라 무작위 방식으로 개별 데이터 비트를 섞는 방식
      • 예를 들어, 공통 128비트 고급 암호화 표준(AES, Advanced Encryption Standard)로 암호화 된 파일의 경우 이 파일을 구성하는 비트는 약 10회 스크램블 되며 다른 컴퓨터가 키 없이 해독하려면 아주 오랜 시간이 걸린다.
  1. 대칭 암호화
      • 대칭 암호화는 키를 하나만 사용하는 암호화 방법이다.
      • 일반적으로 사용되는 대칭 암호화 알고리즘은 DES, AES가 있다.
      • Plaintext + key = ciphertext // Ciphertext + key = plaintext
  1. 비대칭 암호화
      • 공개키 암호화
      • 공개 키 암호화는 두 개의 다른 키(공개 키, 개인 키)로 데이터를 암호화하거나 서명하고 키 중 하나인 공개 키를 누구나 사용할 수 있도록 하는 방법이다.
      • 공개 키로 암호화된 데이터는 개인키로만 복호화할 수 있다.
      • 일반적으로 사용되는 비대칭 암호화 알고리즘은 RSA, DH(Diffie-Hellman)이 있다.
      • HTTPS를 가능하게 하는 프로토콜인 TLS는 부분적으로 비대칭 암호화를 쓴다.
      • 비대칭 암호화로 인증을 한 후 대칭 암호화로 보안적 통신을 시작한다.
      • TLS 핸드셰이크 과정에서 처음 인증할 때 비대칭암호화를 하고 그 이후 클라이언트와 서버는 세션 키를 기반으로 대칭 암호화 기반의 암호화 통신을 한다.
  1. 암호화의 필요성
      • 암호화는 의도된 수신자 또는 송신자를 제외하고는 통신을 하이재킹하여 읽을 수 없게 한다.
      • 민감한 데이터의 유출을 방지하고 데이터 무결성을 보장한다.
  1. TLS 핸드셰이크
      • SSL(Secure Socket Layer)는 SSL 1.0부터 시작해서 SSL 2.0, SSL 3.0, TLS(TransportLayer Security Protocol) 1.0, TLS 1.3까지 버전이 올라가며 마지막으로 TLS로 명칭이 변경되었다.
      • TLS는 전송 계층에서 보안을 제공하는 프로토콜이다.
      • 클라이언트와 서버가 통신할 때 TLS를 통해 제 3자가 메시지를 도청하거나 변조하지 못하도록 한다.
      • 사용할 TLS 버전을 정하고, 사이퍼슈트, 서버의 공개 키, SSL 인증서를 기반으로 인증작업을 수행한다. 이후 대칭 암호화를 위해 세션 키를 생성한다.
          1. Client Hello
              • 클라이언트는 TLS버전, 사이퍼슈트와 클라이언트 랜덤값, 임시 DH 매개변수를 서버에 보낸다.
          1. Server Hello, EncryptedExtensions, Certificate, CertificateVerify
              • 서버는 클라이언트로부터 받은 옵션을 확인한다. 서버와 클라이언트 모두에서 지원하는 가장 높은 TLS 버전을 식별하며 결정, 사이퍼슈트 지원 여부를 확인한다. 공개 키가 포함된 SSL 인증서, 서버 랜덤값, 임시 DH 매개변수를 보낸다. 클라이언트와 서버 각각 서로 교환한 DH 매개변수를 사용하여 세션키를 생성한다.
          1. Finished
              • 서버와 클라이언트 모두 이전에 교환된 모든 메시지에 대한 무결성과 인증을 확인하는 메세지를 보내고 클라이언트와 서버, 세션키를 기반으로 대칭 암호화된 통신이 시작된다. (보안 세션의 시작)
              • 키 교환 알고리즘으로는 대표적으로 RSA, DH가 있다. TLS1.3에서는 RSA의 경우 취약점이 있기 때문에 공식적으로 지원하지 않는다. 대신 타원곡선 DH를 사용한다.
      • DH 매개변수
        • Diffie-Hellman 알고리즘은 서로 공개 값 공유 -> 비밀 값과 혼합 -> 혼합 값 공유 -> 각자의 비밀 값과 혼합 의 과정을 통해 공통의 암호키를 만드는 알고리즘이다.
        • DH에는 그냥 디피헬만을 사용하는 DHE / 타원곡선 암호화방법과 DH를 섞은 ECDHE가 있고 보통 ECDHE를 쓴다.
          • 타원곡선 암호화
            • 곡선을 사용하여 개인 키 보유자만 알 수 있는 타원곡선을 그린다.
            • 이를 기반으로 교차점을 생성하고 교차점의 수를 기반으로 암호를 설정한다.
      • 사이퍼슈트
        • 프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약을 뜻한다.
        • 암호제품군이라고도 한다.
        • TLS1.3에는 다섯 개의 방식이 존재한다.
          • TLS_AES_128_GCM_SHA256
          • TLS_AES_256_GCM_SHA384
          • TLS_CHACHA20_POLY1305_SHA256
          • TLS_AES_128_CCM_SHA256
          • TLS_AES_128_CCM_8_SHA256
        • AEAD 사이퍼 모드
          • AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘이다.
        • 해싱 알고리즘
          • 데이터를 추정하기 힘든 더 작고, 섞여 있는 조각으로 만드는 알고리즘
          • SSL/TLS는 해싱 알고리즘으로 SHA256, SHA384를 쓴다.
          • SHA256은 해시 함수의 결괏값이 256비트인 알고리즘이다.
          • 인증서가 올바른 인증서인지 확인할 떄 전사서명을 이용하는데 이 때 해싱 알고리즘이 쓰인다.
            • 인증 생성, 인증 확인 작업을 거친다.
            • 인증 생성작업에서는 전자 서명 메시지를 해싱하고 확인작업에서는 메시지를 복호화해서 해시를 서로 비교하여 올바른 메시지인지 확인한다.
        • 인증서
          • 인증서는 1. 주체, 2. 공개키 를 포함하는 데이터 파일이다.
          • 보통 인증기관인 CA에서 발급한 SSL 인증서를 기반으로 인증작업을 수행한다.
          • 주체는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 확인할 때 쓰이고 공개 키는 처음 인증작업을 수행할 때 쓰인다.
        • CA
          • 인증서를 발급하는 기업들을 CA(Certificate Authority)라고 한다.
          • 서비스의 도메인, 공개 키와 같은 정보는 서비스가 CA로부터 인증서를 구입할 때 제출해야 한다.
          • 인증서의 종류
            • 단일 도메인: 단 하나의 도메인에 적용되는 인증서
            • 와일드카드: 도메인의 하위 도메인도 포함하는 인증서
            • 멀티 도메인: 관련되지 않은 다수의 도메인에도 적용될 수 있는 인증서
  1. RSA의 취약점
      • RSA의 경우 클라이언트가 생성한 임시 암호값을 서버로 전송하지만 DH의 경우 클라이언트와 서버가 서로 교환한 DH 매개변수를 사용해 개인 키를 만든다. 이 때문에 RSA는 클라이언트에서 생성한 임시 암호값이 탈취당한 경우 해킹의 위험이 있다. 그러나 DH의 경우 탈취당해도 공통의 암호 키를 못 만들기 때문에 보안성이 더 좋다.
  1. 0 - RTT
      • 세션 키가 생성된 이후 다시 그 사이트에 방문하면 미리 만들어 놓은 세션키(PSK, pre-shared key)를 기반으로 연결을 생성하기 때문에 이 때부터는 인증에 드는 비용이 없다. 따라서 인증에 관한 RTT가 발생하지 않기 때문에 0 - RTT가 된다.

브라우저의 캐시

  1. 로컬스토리지의 개념
      • 로컬스토리지는 웹 스토리지 객체오 브라우저 내에 key : value 형태로 오리진에 종속되어 저장되는 데이터이다.(오리진이 같은 브라우저 내에서 공유된다.)
      • 하나의 키에 오로지 하나의 값만 저장된다.
      • 데이터는 사용자가 브라우저에서 수동으로 삭제하지 않는 한 평생동안 로컬 저장소에 저장되며 만료 날짜가 없다. 사용자가 창이나 탭을 닫아도, 컴퓨터를 종료해도 만료되지 않는다.
      • 최대 저장용량은 5MB다.
      • 보통 사용자의 행위를 기억할 때, 로그인을 유지하기 위한 값 등으로 사용되며 로컬 스토리지 데이터는 자동으로 서버로 전송되지 않는다. (쿠키는 자동으로 전송된다.)
  1. 오리진
    1. notion image
  • 위의 이미지의 주소 부분에서 포트번호까지의 경로를 오리진이라고 한다.
  • 로컬 스토리지는 오리진에서 공유된다는 뜻은 이 경로까지가 같은 부분에 대해서 페이지를 이동하든 해도 로컬스토리지가 공유된다는 뜻이다.
  1. 로컬스토리지의 활용 예시: 검색기록 캐싱
  • 특정 검색기록 목록을 보여주기 위해 검색을 할 때마다 로컬스토리지에 저장하여 검색기록을 캐싱한다.
  1. 세션스토리지
  • 세션스토리지 또한 로컬스토리지 처럼 key : value 형태로 오리진에 종속되어 자장되는 데이터다.
  • 다만 세션스토리지는 브라우저의 각 탭마다 독립적으로 저장된다. 탭 간에는 간섭이 없다.
  • 최대 저장용량은 마찬가지로 5MB다.
  • 브라우저에서 탭을 닫으면 데이터는 만료된다.
  • 보통은 세션스토리지보다 로컬스토리지를 더 많이 쓴다.
  1. 쿠키
  • 쿠키는 브라우저에 저장된 데이터 조각이다. 클라이언트에서 먼저 설정할 수도 있고 서버에서도 먼저 설정할 수도 있으나 보통은 서버에서 먼저 설정하는 게 일반적이다.
  • 서버에서 응답헤더로 Set-Cookie를 넣으면 그 때부터 클라이언트에서 요청헤더 Cookie에 설정되어 자동으로 서버에 전달되게 되고 브라우저에도 저장된다.
  • 쿠키의 생명주기는 보통 서버에서 만료기한 등을 설정한다.
  • 쿠키의 최대 저장용량은 4kb이다.
  • 보통 로그인, 장바구니, 사용자 커스터마이징, 사용자 행동분석(광고)에 사용된다.
  • 세션 쿠키
    • 세션 쿠키는 Expires 또는 Max-Age 속성을 지정하지 않는 것이다. 브라우저가 종료되면 쿠키도 삭제된다.
  • 영구 쿠키
    • 영구 쿠키는 Expires 또는 Max-Age 속성을 지정해서 특정 날짜 또는 일정 기간이 지나면 삭제되게 만든 쿠키이다. 브라우저를 닫는다고 만료되지 않는다.
  • 사용법
    • Set-Cookie: <cookie-name>=<cookie-value> Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date> Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit> Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value> Set-Cookie: <cookie-name>=<cookie-value>; Secure Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
  • secure
    • 쿠키에 secure를 쿠가하면 https로만 쿠키를 주고받을 수 있게 된다.
    • 하지만 크롬, 파폭 특정 버전 이상에서는 테스트의 편의성을 위해 localhost에서는 이를 무시한다.
  • httponly
    • 공격자가 쿠키를 자바스크립트로 빼낼 수 없게 만든다. (document.cookie로 접근 불가)
  • samesite
    • 요청이 동일한 도메인에서 시작된 경우에만 쿠키가 애플리케이션으로 전송되도록 허용하는 옵션.

로컬스토리지, 세션스토리지, 쿠키의 공통점과 차이점

공통점

  1. 브라우저에 캐싱을 함으로써 서버에 대한 요청을 줄여 서버부하를 방지할 수 있다.
  1. 캐싱으로 인해 다운로드 하는 컨텐츠가 줄어들어 웹사이트의 컨텐츠를 더 빨리 다운로드 할 수 있게 된다.
  1. 사이트 테마 커스터마이징 등을 저장하거나 로그인 상태를 유지할 때 사용될 수 있다.차이점
notion image
  • 쿠키와 로컬스토리지는 오리진이 같은 여러 개의 창이나 탭을 닫아도 유지된다.

로그인 방식

개념

로그인은 세션기반 인증방식 또는 토큰기반 인증방식으로 구현된다.
HTTP의 특징은 stateless하다는 것이 있다. HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는 특징이 있다는 것이다.
따라서 HTTP 기반으로 로그인 기능을 구현했을 때 로그인 상태를 어떻게 유지해야 하는가?라는 의문이 생긴다.
이를 가능하게 해주는 방식이 세션기반과 토큰기반의 2가지로 나뉜다.

세션기반 로그인 프로세스

  1. 로그인 -> sessionId 생성 -> 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
  1. 클라이언트가 서버에 요청을 보낼 때 해당 세션ID를 쿠키로 담아서 전에 로그인했던 아이디인지 확인
  1. 로그인을 유지

세션기반의 단점

  • 사용자의 상태에 관한 데이터를 서버에 저장했을 때 로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부화가 일어날 수 있다.
  • DB 중 RDBMS에 저장한다면 직렬화 및 역직렬화에 관한 오버헤드가 발생한다.

토큰기반인증방식

토큰 기반 인증방식은 state를 모두 토큰 자체 만으로 처리하며 토큰을 처리하는 한 서버를 두고 다른 컨텐츠를 제공하는 서버는 모두 stateless하게 만드는 방식이다.
모놀리식한 구조 하에 인증을 구현하게 되면 어느 한 군데가 망가지면 인증체계까지 모두 에러가 나서 어떤 기능도 사용할 수 없는 상태가 될 수 있다.
보통의 MSA식 구조 하에서는 인증 서버를 따로 만들어서 토큰을 인증서버를 통해 관리하게 된다.
토큰은 주로 JWT(Jason Web Token)을 사용한다.
인증서버에서 인증로직을 거쳐 JWT(access 토큰, refresh 토큰)를 생성한 뒤 클라이언트에서 access 토큰을 HTTP header - Authorization 또는 Cookie에 담아 인증이 필요한 서버에 요청하는 방식이다.

JWT 방식의 장점

  1. 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함되어 있기 때문에 별도의 인증 저장소가 필요 없다.
  1. 다른 유형의 토큰과 비교했을 때 경량화되어 있다. SAML과 비교해보면 확연히 짧다.
  1. 디코딩했을 때 JSON이 나오기 떄문에 직렬화, 역직렬화가 간편하다.

JWT 방식의 단점

  1. 토큰이 비대해질 경우 서버과부화를 일으킬 수 있다.
  1. 토큰이 탈취당하는 경우 디코딩했을 때 데이터를 볼 수 있다

주의할 점

access 토큰을 얻은 후에 요청할 때는 HTTP Header - Authorization 또는 Cookie에 담아 요청을 하게 되는데 권장되는 규칙이 있다.
  • Bearer {token} 으로 토큰값 앞에 Bearer라는 문자열을 붙여서 토큰기반 인증방식이라는 것을 알려준다.
  • https를 사용해야 한다.
  • 쿠키에 저장한다면 sameSite: 'Strict'를 써야 한다.
  • 수명이 짧은 access token을 발급해야 한다.
  • url에 토큰을 전달해선 안된다.

토큰 탈취에 대비하는 방법

  1. Access 토큰의 수명을 짧게 하여 탈취된 토큰의 유효 기간을 최소화한다. 필요할 때만 Refresh 토큰을 통해 새로운 Access 토큰을 발급받는다.
  1. Refresh Token을 사용하여 민감한 작업을 수행하려고 할 때 추가적인 사용자 인증단계를 요구한다. 예를 들어 IP 주소, 디바이스 정보 등을 이용하거나 google authenticator를 이용한 2FA(2 factor authentication)을 이용한다.
  1. 쿠키에 HttpOnly 및 Secure를 걸어서 관리한다.

자주 등장하는 HTTP 상태코드

1xx (정보)

서버가 요청을 잘 받았으며 해당 프로세스를 계속 이어가며 처리하는 것.
  • 100: 계속함을 의미

2xx (성공)

서버가 요청을 잘 받았고 이를 기반으로 클라이언트에게 성공적으로 데이터를 보낸 것을 의미한다.
  • 200 OK : 요청이 성공적으로 되었다.
  • 201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었다.

3xx (리다이렉션)

서버가 클라이너트의 요청에 대해 완료를 위해 추가 작업 조치가 필요하다.
  • 301 Moved Permanently: 이 응답코드는 요청한 리소스의 URI가 변경되었음을 의미한다.
  • 변경된 새로운 URI를 301 상태코드와 함께 주어야 한다.

4xx (클라이언트 오류)

클라이언트가 요청한 페이지를 제공할 수 없거나 클라이언트의 요청이 잘못되어 결과적으로 요청을 처리할 수 없다.
  • 400 Bad Request: 서버가 클라이언트 요청을 이해할 수 없음
  • 401 Unauthorized: 클라이언트의 인증이 되지 않음.
  • 404 Not Found: 요청받은 컨텐츠를 찾을 수 없다.

5xx (서버 오류)

서버가 클라이언트의 요청을 처리하지 못하는 상태
  • 500 Internal Server Error: 서버에 오류가 있음.
  • 502 Bad Gateway: 게이트웨이 또는 프록시서버가 오류가 생겼음.
  • 504 Gateway Timeout: 게이트웨이 또는 프록시서버가 정해진 Timeout 시간동안 클라이언트의 요청을 처리하지 못함.

HTTP 메서드

HTTP의 메서드의 종류

  1. GET
  1. POST
  1. PUT
  1. HEAD
  1. DELETE
  1. PATCH
  1. OPTIONS
  1. CONNECT
  1. TRACE

GET: 데이터를 읽는다.

  • url을 기반으로 데이터를 요구하는 방법이다.
  • url을 기반으로 하기 때문에 길이 제한 (2000자 미만)이 있다.
  • 성공시 HTTP 상태코드 200을 반환한다.
  • 캐싱이 가능하다.
  • url을 기반으로 요청하기 때문에 해당 요청의 파라미터가 브라우저 기록에 남는다.
  • url을 기반으로 요청하기 때문에 요청할 때 ASCCII문자열만 보낼 수 있다.
  • 사용자 이름, 비밀번호 등 민감한 정보를 전달할 때 사용하지 않는다.

POST: 데이터를 생성한다.

  • url이 아닌 HTTP message body를 통해 데이터를 전달한다.
  • HTTP body를 통해 전달되기 때문에 길이 제한이 없다.
  • 성공적으로 데이터를 생성할 경우 HTTP 상태코드 201을 반환한다. (생성한 경우 201, 생성하지 않은 경우 200을 반환하기도 함.)
  • 캐싱이 불가능하다.
  • url을 기반으로 요청하지 않기 때문에 해당 요청의 파라미터가 브라우저 기록에 남지 않는다.
  • HTTP body로 요청하기 때문에 ASCII 뿐만 아니라 모든 유형의 데이터를 기반으로 요청할 수 있다.
  • 사용자 이름, 비밀번호 등 민감한 정보를 전달할 때 사용한다.

PUT과 PATCH의 차이

PUT: 업데이트하는 데이터의 전체를 보낸다.

요청을 보낼 때 해당 데이터 전체를 보내야 하고 전체 데이터의 교체를 의미한다.
또한 PUT은 만약 해당 데이터가 없다면 새로이 생성하고 있다면 해당 데이터가 요청할 때 보낸 데이터로 교체한다.

PATCH: 업데이트하는 데이터의 일부를 보낸다.

요청을 보낼 때 수정하는 일부분만 보내면 되고 일부분의 교체를 의미한다.