OSI 7계층
7계층을 나누는 이유
- 통신이 일어나는 과정을 단계별로 알 수 있고, 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 떄문
- 물리 계층
- 케이블, 허브
- 데이터를 전기적인 신호로 변환해서 주고 받는 기능을 진행하는 공간
- 데이터 링크 계층
- 물리 계층으로 송 수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할
- 비 신뢰적 물리 회선을 신뢰적 링크로 변환
- Mac 주소를 통해 통신
- 프레임에 Mac 주소를 부여하고 에러검출, 재전송, 흐름제어를 진행한다.
- 네트워크 계층
- 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당
- 라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.
- 라우팅, 흐름제어, 오류제어, 세그먼테이션 수행
- 전송 계층
- TCP, UDP 프로토콜을 통해 통신을 활성화 한다.
- 포트를 열어두고 프로그램들이 전송을 할 수 있도록 해준다.
- 세션 계층
- API, Socket
- 데이터가 통신하기 위한 논리적 연결을 담당한다.
- TCP/IP 세션을 만들고 없애는 책임을 지니고 있다.
- 표현 계층
- JPEG, MPEG 등
- 데이터 표현에 대한 독립성을 제공하고 암호화 하는 역할
- 응용 계층
- HTTP, FTP, DNS 등
- 최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
TCP & UDP
TCP
연결 지향 프로토콜로 마치 물리적인 선으로 연결되어 있는 것처럼 가상의 연결 통로를 설정하여 통신, 흐름제어, 혼잡제어, 오류제어를 제공
3-way Handskake
3 방향 핸드쉐이크를 통해 TCP 연결 
- 클라이언트는 서버에 접속을 요청하는 SYN(M) 패킷을 보낸다
- 서버는 클라이언트의 요청인 SYN(M)을 받고 요청을 수락한다는 ACK(M+1)와 SYN(N)이 설정된 패킷을 발송한다
- 클라이언트는 서버의 수락 응답인 ACK(M+1)와 SYN(N) 패킷을 받고 ACK(N+1)를 서버로 보내면 연결이 성립한다
4-way Handshake
4방향 핸드쉐이크를 통해 TCP연결을 해제한다
- 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다
- 서버는 FIN을 받고 확인 메시지로 ACK를 보낸다
- 데이터를 모두 보낼때 까지 잠깐 TIME_OUT가 된다.
- 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다
- 클라이언트는 FIN플래그를 받고 확인했다는 ACK를 보낸다
- 클라이언트의 ACK 메시지를 받은 서버는 소켓 연결을 close 한다
- 클라이언트는 아직 서버로 부터 받지 못한 데이터가 있을 것을 대비하여 일정 시간동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 가진다
UDP
비 신뢰성 서비스로 수신측에 제대로 도착했는지 확인 여부를 보장하지 않는다.
- 연결 자체가 없어 서버 소켓과 클라이언트 소켓의 구분이 없다.
- 소켓 대신 IP 기반으로 데이터 전송
- 서버와 클라이언트는 1:1, 1:N, M:N 등으로 연결
- 데이터그램 단위로 전송되며 크기는 65535바이트로 크기가 초과하면 잘라서 보낸다.
- 흐름제어가 없어서 전송이 제대로 되었는지 오류가 없는지 확인할 수 없다.
- 파일전송과 같이 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우 사용
TCV vs UDP
프로토콜
인터넷 상에서 통신을 위해 상호간에 정의한 규칙
HTTP와 HTTPS
HTTP
인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 사용하는 통신규약
- HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다.
- 상태가 없는 프로토콜 => 데이터를 주고 받기 위한 각각의 데이터 요청을 서로 독립적으로 관리
- 클라이언트에서 서버에 요청하면 서버는 클라이언트에 응답을 하고 접속을 끊음
- 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버 부하를 줄일 수 있는 성능상의 이점이 있다.
HTTP 요청 메소드
- GET : 존재하는 자원에 대한 요청
- POST : 새로운 자원을 생성
- PUT : 존재하는 자원에 대한 변경
- PATCH : 존재하는 자원의 부분적인 수정을 할 때 사용
- DELETE : 존재하는 자원에 대한 삭제
- HEAD : 서버 헤더 정보를 획득. GET과 비슷하나 Response Body를 반환하지 않음
- OPTIONS : 서버 옵션들을 확인하기 위한 요청. CORS에서 사용
멱등성
같은 요청을 반복하는 경우 요청에 따른 서버의 상태가 같아야함
- 안전한 메소드는 서버의 상태를 변경시키지 않음 ex) GET
- 멱등한 메소드는 서버의 상태를 변경시킬수도 있고 아닐 수도 있음 ex) PUT, DELETE, GET
HTTP 버전
- 0.9 단순하게 GET만 사용이 가능하고, 헤더가 없기 떄문에 HTML 문서만 전송할 수 있다. 오류코드가 없어서 해당 파일 내부에 문제에 대한 설명을 포함해서 보냄
- 1.0 상태코드가 응답의 시작 부분에 포함되어 성공과 실패를 바로 확인할 수 있고, 헤더가 추가되어 확장이 가능해짐
- 1.1 첫번째 표준 버전으로 OPTION, PUT, DELETE, TRACE이 추가, 헤더도 몇가지 추가 됨. 성능 향상을 위해 일정 시간 동안 연결 정보를 기억하여 반복적으로 일어나는 통신에 연결의 맺고 끊음을 줄였다.
- 2.0 바이너리 포맷으로 인코딩 된 Message와 Frame로 구성됨. 스트림을 사용해서 한 번의 커넥션으로 여러개의 데이터를 동시에 주고 받을 수 있다. 이전 헤더내용과 중복되는 필드를 재전송하지 않아 데이터를 절약할 수 있다. 헤더를 허프만 코딩을 사용하는 HPack라는 압축방식을 사용해서 전송 효율을 높였다. 스트림에 우선순위를 줄 수 있다.
- HOL Blocking 문제 해결 한 번에 하나의 파일만 요청했기 때문에 선행하는 파일이 늦어지면 전체 파일 전송이 느려졌지만, 한 번에 병렬로 전송하며 이러한 문제를 해결하였다.
- 3.0 QUIC 기반의 HTTP QUIC : TCP의 신뢰성과 UDP의 빠른 성능을 토대로 구현, UDP 기반으로 만들어졌으며 대역폭을 예상해서 패킷 혼잡을 피할 수 있다.
HTTPS
HTTP에 암호화와 인증, 완전성 보호를 더한 것
- HTTP 통신하는 소켓 부분을 SSL or TLS라는 프로토콜로 대체하여 사용
- HTTPS의 SSL에서는 대칭키 암호화 방식과 비 대칭키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용.
HTTPS방식에서 대칭키와 비 대칭키 암호화 방식을 같이 사용하는 이유
- 비 대칭키 암호화 방식을 지속적으로 사용할 경우 RSA 알고리즘을 사용하는데, 기존 대칭키 암호화 방식에 비해 연산량이 많아 성능에 문제가 생길 수 있다. 따라서, 대칭키를 얻기 위해 비 대칭키 암호화 방식을 사용하고 이후 대칭키를 사용해서 통신한다.
대칭키 암호화 방식
하나의 키로 평문을 암호화 하고, 다시 암호문을 원래의 평문으로 복호화 할때 사용하는 방식
비 대칭키 암호화 방식
공개키와 비밀키 두개를 가지며, 공개키로 암호화 한 것은 비밀키로 복호화 할 수 있으며 비밀키로 암호화 한 것은 공개키로 복호화 하는 방식
SSL/TLS HandShake
- 클라이언트는 서버에게 Client Hello 요청을 보낸다. 요청에는 SSL or TLS 버전 정보, 지원하는 암호화 방식, 임의의 난수 등을 포함된다.
- 서버는 클라이언트에게 Server Hello 응답을 보낸다. 응답에는 서버의 공개키가 담긴 SSL 인증서, 임의의 난수 등을 포함된다.
- 클라이언트는 서버로 부터 받은 인증서를 검증한다.
- 클라이언트는 자신이 생성한 난수와, 서버가 생성한 난수를 사용해서 premaster secret를 만들고 CA의 공개키로 암호화 해서 서버에게 보낸다.
- 서버는 비밀키를 통해 premaster secret의 값을 복호화 한다.
- 서버와 클라이언트 모두 대칭키를 가지고 있으므로, premaster secret를 통해 암호화, 복호화 하며 HTTPS 통신을 진행한다
쿠키와 세션
쿠키
클라이언트에 저장되는 키와 값들이 들어있는 작은 텍스트 파일, 이름 값 옵션을 저장
- 옵션
- HttpOnly 브라우저에서 쿠키에 접근할 수 없어서 xss공격을 예방할 수 있다.
- Secure https일때만 쿠키를 전송한다.
- maxAge 쿠키의 수명을 설정한다.
- sameSite 외부 사이트에 쿠키의 전송 범위를 결정하는 옵션으로 csrf공격을 방어하기 위한 옵션으로 사용될 수 있다.
- None : 쿠키 사용에 있어서 소스가 되는 주소를 검증하지 않음
- Lax : Strict 정책에서 몇가지가 예외처리 됨
- Strict : sameSite일때만 쿠키를 전송
- SameSite 기준 : 쿠키의 주소와 브라우저 주소창 URI의 eTLD + 1 Level이 일치할 경우 sameSite이다. 07버전부터는 Scheme까지 같아야 sameSite
세션
일정 시간동안 같은 브라우저에서 들어오는 요청을 하나의 상태로 보고 그 상태를 서버에 저장하는 기술
쿠키 vs 세션
CORS
Cross-Origin Resoruce Sharing로 서로 다른 Origin에서 리소스를 공유할 수 있도록 하기 위한 정책
- 다른 Origin : 도메인 혹은 포트가 다른 상황
- Same-Origin-Policy : 웹 브라우저의 보안을 위해 프로토콜, 호스트, 포트가 동일한 서보로만 요청을 주고받을 수 있는 정책
기본적으로 SOP를 따르기 때문에 다른 Origin과 리소스를 공유하기 위해 CORS를 사용한다.
REST
Representational State Transfer의 약자로 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
- 구성요소
- 자원 : URI
- 행위 : HTTP METHOD
- 표현
- 특징
- 유니폼 인터페이스 HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용해도 사용이 가능하다.
- Stateless 상태를 저장하지 않고 서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리. 이전 요청이 다음 요청에 영향을 미치지 않음
- 캐시 HTTP의 기존 웹 표준을 사용하기 때문에 HTTP가 가진 캐싱 기능을 적용 가능하다
- 자체 표현 구조 REST API 메시지만 보고 쉽게 이해할 수 있는 표현 구조로 되어있다.
REST API
REST 기반의 규칙들을 지켜서 설계된 API를 REST API 라고한다.
- 설계 규칙
- URI는 정보의 자원을 표현해야한다. 자원의 이름은 동사보다 명사
- 자원에 대한 행위는 HTTP METHOD를 사용한다.
- 슬래시는 계층 관계를 나타낼 때 사용한다.
- URI 마지막은 슬래시를 사용하면 안된다.
- 하이픈은 가독성을 높이기 위해 사용한다
- 언더바는 사용하지 않는다
- 경로에 소문자를 사용하고 대문자 사용을 피한다.
- 파일 확장자는 URI에 포함되지 않는다.
RESTful API
Restful의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
URI, URL, URN
- URI (Uniform Resource Identifier)
- 자원을 고유하게 식별하고 위치를 지정하는 통합 자원 식별자
- 인터넷 프로토콜을 명시
- URL (Uniform Resource Location)
- 특정 서버의 한 리소스에 대한 구체적인 위치
- 자원의 위치와 접근 방법을 알려줌
- URN (Uniform Resource Name)
- 자원의 위치와 독립적인 이름
- URL이 변경되면 기존의 객체를 찾을 수 없다는 URL의 한계를 극복하기 위해 사용
로드밸런싱
- 서버에 부하가 일어나지 않도록 여러 서버에 분산하는 방식
- 물리 장비를 이중화 해서 구현하거나, nginx와 같은 서버를 이용하여 구현
JWT
Json Web Token으로 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 웹 토큰 구성요소
- Header: 타입과 암호화 알고리즘
- PayLoad: jwt의 내용, 속성들을 클레임 셋이라고 부른다.
- Signature: 헤더와 페이로드를 합친 문자열에 헤더에 포함된 알고리즘과 비밀키를 이용해 생성하고 인코딩한 것 헤더와 페이로드는 인코딩만 되어있고 암호화 되어있지 않다. 변조의 위험이 있기 때문에 유효성 검사를 위해 시그니처를 사용한다. 문제점
- 토큰이 탈취된다면 토큰의 유효성을 검증할 수 없다.
- 헤더와 페이로드는 암호화 되어있지 않고 인코딩만 되어있기 떄문에, 디코딩만 하면 정보를 탈취할 수 있다.