네트워크
IP / IP Packet
IP는 IP 주소(IP address)에 패킷이라는 통신 단위로 데이터를 전달합니다.
IP 프로토콜의 대표적인 단점
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송합니다.
- 비신뢰성
- 중간에 패킷이 사라질 수 있고, 패킷의 순서를 보장할 수 없습니다.
TCP vs UDP
TCP(전송 제어 프로토콜, Transmission Control Protocol)
- 연결 지향 - TCP 3 way handshake(가상 연결)
- 데이터 전달 보증
- 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.
- 순서 보장
- 만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있습니다.
- 신뢰할 수 있는 프로토콜
UDP(사용자 데이터그램 프로토콜, User Datagram Protocol)
- 비 연결 지향
- 데이터 전달 보증 X
- 순서 보장하지 않음
- 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
- 신뢰성보다는 연속성이 중요한 서비스에 자주 사용됨
TCP vs UDP
| TCP | UDP |
| 연결지향형 프로토콜 | 비 연결지향형 프로토콜 |
| 전송 순서 보장 | 전송 순서 보장하지 않음 |
| 데이터 수신 여부 확인함 | 데이터 수신 여부 확인하지 않음 |
| 신뢰성 높음 | 신뢰성 낮음 |
| 속도 느림 | 속도 빠름 |
OSI 7계층 모델과 TCP/IP 4계층 모델

OSI 7계층 모델
- 1계층 - 물리 계층
- 시스템 간의 물리적인 연결과 전기 신호를 변환 및 제어하는 계층입니다.
- 주로 물리적 연결과 관련된 정보를 정의합니다.
- 주로 전기 신호를 전달하는데 초점을 두고, 들어온 전기 신호를 그래도 잘 전달하는 것이 목표입니다.
- 2계층 - 데이터링크 계층
- 네트워크 기기 간의 데이터 전송 및 물리주소를 결정하는 계층입니다.
- 물리 계층에서 들어온 전기 신호를 모아 알아볼 수 있는 데이터 형태로 처리합니다.
- 이 계층에서는 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행합니다.
- 3계층 - 네트워크 계층
- OSI 7 계층에서 가장 복잡한 계층 중 하나로서 실제 네트워크 간에 데이터 라우팅을 담당합니다.
- 4계층 - 전송 계층
- 컴퓨터 간 신뢰성 있는 데이터를 서로 주고받을 수 있도록 하는 서비스를 제공하는 계층입니다.
- 하위 계층에서 신호와 데이터를 올바른 위치로 보내고 신호를 만드는데 집중했다면, 전송 계층에서는 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 합니다.
- 네트워크 계층에서 사용되는 패킷은 유실되거나 순서가 바뀌는 경우가 있는 데, 이를 바로 잡아주는 역할도 담당합니다.
- 5계층 - 세션 계층
- 세션 연결의 설정과 해제, 세션 메시지 전송 등의 기능을 수행하는 계층입니다.
- 컴퓨터 간의 통신 방식에 대해 결정하는 계층이라고 할 수 있습니다.
- 6계층 - 표현 계층
- 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층입니다.
- 일종의 번역기 같은 역할을 수행하는 계층이라고 볼 수 있습니다.
- 7계층 - 응용 계층
- 사용자와의 인터페이스를 제공하는 계층으로 사용자가 실행하는 응용 프로그램들이 해당 계층에 속합니다.
데이터의 캡슐화
OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고 받습니다. 각 계층은 독립적이므로 데이터가 전달되는 동안에 다른 계층의 영향을 받지 않습니다.
데이터를 전송하는 쪽은 상위 계층에서 하위 계층으로 데이터를 전달하는데, 이때 데이터를 보낼 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 합니다. 그리고 이렇게 헤더를 붙여나가는 것을 캡슐화라고 합니다.
데이터를 받는 쪽은 하위 계층에서 상위 계층으로 각 계층을 통해 전달된 데이터를 받게 됩니다. 이때 상위 계층으로 데이터를 전달하며 각 계층에서 헤더를 제거해 나가는 것은 역캡슐화라고 합니다. 역캡슐화를 거쳐 마지막 응용 계층에 도달하면 원본 데이터만 남게 됩니다.
TCP/IP 4계층 모델
TCP/IP 4계층 모델은 OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델입니다.
- 1계층 - 네트워크 인터페이스 계층
- OSI 계층의 물리 계층과 데이터 링크 계층에 해당하며 물리적인 주소로 MAC을 사용합니다.
- 2계층 - 인터넷 계층
- OSI 계층의 네트워크 계층에 해당하며 통신 노드 간의 IP 패킷을 전송하는 기능 및 라우팅을 담당합니다.
- 3계층 - 전송 계층
- OSI 계층의 전송 계층에 해당하며 통신 노드 간의 연결을 제어하고, 신뢰성 있는 데이터 전송을 담당합니다
- 4계층 - 애플리케이션 계층
- OSI 계층의 세션 계층, 표현 계층, 응용 계층에 해당하며 TCP/UDP 기반의 응용 프로그램을 구현할 때 사용합니다.
HTTP
- 클라이언트 서버 구조
- 클라이언트와 서버의 Request / Response 구조
- 무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존하지 않아 서버 확정성이 높지만, 클라이언트가 추가 데이터를 전송하는 단점이 있다.
- 비연결성(Connectionless)
- 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는 시스템으로 최소한의 자원으로 서버 유지를 가능하게 해 효율적입니다.
- 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 한계가 있습니다.
- HTTP 메시지
- 단순함, 확장 가능

HTTP Requests
- HTTP Requests는 클라이언트가 서버에서 보내는 메시지입니다.
- Start line
- 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냅니다
- 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다
- origin 형식
- '?'와 쿼리 문자열이 붙는 절대 경로입니다. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용합니다.
- absolute 형식
- 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.
- authority 형식
- 도메인 이름과 포트 번호로 이루어진 URL의 일부분 입니다. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있습니다.
- asterisk 형식
- OPTIONS와 함께 별표(*) 하나로 서버 전체를 표현합니다.
- origin 형식
- HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력합니다.
- Headers
- 요청의 Headers는 기본 구조를 따릅니다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력합니다. 값은 헤더에 따라 다릅니다.
- Header 종류
- General headers
- 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
- Request headers
- fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다.
- User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다.
- Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
- Representation headers
- 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
- General headers
- 요청에서 사용되는 헤더
- Form : 유저 에이전트의 이메일 정보, 검색 엔진에서 주로 사용
- Referer : 이전 엡 페이지 주소, 유입경로 수집 가능
- User-Agent : 유저 에이전트 애플리케이션 정보, 클라이언트 애플리케이션 정보 등 수집 가능
- Host : 요청한 호스트 정보(도메인)
- Origin : 서버로 Post 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더
- Body
- 요청의 본문은 HTTP messages 구조의 마지막에 위치합니다.
- POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.
- GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다.
- Body 종류
- Single-resource bodies(단일-리소스 본문)
- 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
- Multiple-resource bodies(다중-리소스 본문)
- 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다.
- 보통 HTML form과 관련이 있습니다.
- Single-resource bodies(단일-리소스 본문)
HTTP Responses
- HTTP Responses는 서버가 클라이언트에게 보내는 메시지입니다.
- Status line
- 현재 프로토콜의 버전(HTTP/1.1)
- 상태 코드 : 요청의 결과를 나타냅니다.
- 상태 텍스트 : 상태 코드에 대한 설명
- Headers
- 응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있습니다.
- 대소문자 구분 없는 문자열, 콜론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다.
- Header 종류
- General headers
- 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
- Response headers
- 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
- Representation headers
- 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
- General headers
- 응답에서 사용되는 헤더
- Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- Date : 메시지가 발생한 날짜와 시간
- Loation : 페이지 리디렉션
- Allow : 허용 가능한 HTTP 메서드
- Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- Body
- 응답의 본문은 HTTP messages 구조의 마지막에 위치합니다.
- 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다.
- Body 종류
- Single-resource bodies(단일-리소스 본문)
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.
- Multiple-resource bodies(다중-리소스 본문)
- 서로 다른 정보를 담고 있는 body입니다.
- Single-resource bodies(단일-리소스 본문)
콘텐츠 협상 헤더
클라이언트가 선호하는 표현 요청으로 요청시에만 사용
- Accept : 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset : 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
- Accept-Language : 클라이언트가 선호하는 자연 언어
HTTPS
HTTPS는 HTTP Secure 의 약자로, 기존의 HTTP 프로토콜과 달리 요청과 응답으로 오간느 내용을 암호화하기 때문에 더 안전하게 사용할 수 있음을 의미합니다.
암호화 방식
데이터를 암호화를 할 때에는 암호화할 때 사용할 키와 암호화한 것을 해석(복호화)할 때 사용할 키가 필요합니다. 이때 암호화와 복호화할 때 사용하는 키가 동일하다면 대칭 키 암호화 방식, 다르다면 공개 키(비대칭 키) 암호화 방식이라고 합니다.
- 대칭키 암호화 방식
- 하나의 키만 사용하는 방식으로, 암호화할 때 사용한 키와 동일한 키로 복호화가 가능합니다.
- 연산 속도가 빠르다는 장점이 있지만, 키를 주고받는 과정에서 탈취당했을 경우에는 암호화가 소용없어지기 때문에 키를 관리하는데 신경을 많이 써야 합니다.
- 공개 키(비대칭 키) 암호화 방식
- 두 개의 키를 사용하는 방식으로, 암호화할 때 사용한 키와 복호화할 때 사용하는 키가 다릅니다.
- 두 개의 키를 각각 공개 키, 비밀 키라고 부르며 누구든 공개 키를 사용해 암호화한 데이터를 보내면, 비밀 키를 가진 사람만 그 내용을 복호화할 수 있습니다.
- 공개 키가 탈취당하더라도, 비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 좋습니다.
- 하지만 대칭 키 방식보다 더 복잡한 연산이 필요하므로 더 많은 시간을 소모합니다.
SSL/TLS 프로토콜
HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 또는 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행합니다.
- CA를 통한 인증서 사용
- 대칭키, 공개 키 암호화 방식을 모두 사용
인증서와 CA(Certficate Authority)
HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있습니다. 이러한 인증서는 서버의 신원을 보증해 줍니다. 이때 인증서를 발급해 주는 공인된 기관들을 CA라고 부릅니다.
- 서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달합니다
- CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급합니다.
- 서버는 클라이언트에게 요청을 받으면 CA에서 발급받은 인증서를 보내줍니다(이때 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있습니다)
- CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로, 정말로 CA에서 발급한 인증서가 맞는지 확인 후 복호화를 진행합니다.
- 복호화의 성공하면 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 됩니다.
대칭키 전달
사용자가 서버의 인증서를 성공적으로 복호화하여 서버의 공개 키를 확보하면, 이 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고받을 때 사용하게 됩니다. 대칭 키는 오고 가는 과정에서 탈취될 수 있는 위험성이 있지만, 클라이언트가 서버로 대칭 키를 보낼 때 서버의 공개 키를 사용해서 암호화하여 보내준다면, 서버의 비밀 키를 가지고 있는 게 아닌 이상 해당 대칭 키를 복호화할 수 없으므로 탈취될 위험성이 줄어듭니다.
이제 HTTPS 요청을 주고받을 때 이 대칭 키를 사용하여 데이터를 암호화하여 전달하게 됩니다. 요청이 중간에 탈취되어도 제3자가 암호화된 데이터를 복호화할 수 없기 때문에 안전하게 요청과 응답을 주고 받을 수 있습니다.
'프론트엔드 > Section3' 카테고리의 다른 글
| 인증/보안(쿠키,세션) (2) | 2023.05.02 |
|---|---|
| 웹 표준 & 접근성 (3) | 2023.04.25 |
| React 상태관리 Redux (0) | 2023.04.24 |
| React Custom Component (1) | 2023.04.18 |
| 와이어프레임 & 프로토타입 (1) | 2023.04.13 |