✔️ HTTP Request / Response
HTTP
HTTP(HyperText Transfer Protocol)는 HyperText를 전송하기 위한 통신 규약을 의미한다. 웹에서 이루어지는 모든 데이터 교환의 기초이고, TCP/IP 기반이고, 클라이언트-서버 프로토콜이다. 클라이언트-서버 프로토콜에선 클라이언트에 의해 전송되는 메시지를 request라 하고, 요청에 대한 서버의 응답을 response라고 한다.
HTTP는 상태를 저장하지 않고, 세션이라는 것이 존재한다. 각각의 세션 안에서의 요청은 서로 연관성을 가지지 않고 독립적이기 때문에 일관된 방식으로 페이지와 상호작용하길 원한다면 HTTP 쿠키를 사용해 상태를 저장하는 세션을 사용할 수 있다.
Request와 Response의 구조
| Request | Response | |
|---|---|---|
| Start line | ✔️ HTTP method: 요청의 의도를 담고 있는 GET, POST, PUT, DELETE 등이 있다. ✔️ Request target: HTTP request가 전송되는 목표 주소 ✔️ HTTP version: version에 따라 Request 메시지 구조나 데이터가 다를 수 있다. | ✔️ HTTP version ✔️ Status Code ✔️ Status Text |
| Headers | 해당 request에 대한 추가 정보를 담고 있는 부분. 예)✔️ Host: 요청하려는 서버 호스트 이름과 포트번호 ✔️ User-agent: 클라이언트 프로그램 정보. ✔️ Referer: 바로 직전에 머물렀던 웹 링크 주소 등등… | Request의 headers와 동일. User-agent 대신 Server 헤더가 사용된다. |
| Body | HTTP Request가 전송하는 데이터를 담고 있는 부분. 전송하는 데이터가 없다면 body는 비어있다. | Request의 body와 동일. |
참고자료
[Web] HTTP와 Request, Response의 개념 이해
[간단정리] HTTP Request/Response 구조
✔️ TCP / UDP / IP
IP
IP는 인터넷에서 데이터를 목적지까지 보내는 길을 찾아주는 역할을 한다. 인터넷에서 IP 주소를 사용해 컴퓨터를 구분하고 데이터를 보낼 곳을 정한다. 패킷을 한 네트워크에서 다른 네트워크로 전달하고, 주소에 따라 패킷이 올바른 목적지로 가도록 안내한다.
데이터를 보내는 방식에 여러가지가 있다.
- 유니캐스트: 한 명한테만 보내는 것
- 브로드캐스트: 같은 네트워크에 있는 모든 사람에게 보내는 것
- 멀티캐스트: 특정 그룹에 속한 여러 사람에게 동시에 보내는 것
- 애니캐스트: 그룹 중 가장 가까운 한 명에게 보내는 것
IP는 최선은 다하지만 책임은 지지 않는 방식으로 동작한다. 패킷이 손상되거나, 없어지거나, 순서가 뒤죽박죽이 되어도 IP 자체는 이걸 고쳐주지 않는다. 따라서 이런 문제들은 TCP 처럼 IP 위에서 작동하는 다른 프로토콜이 해결해야 한다.
TCP
TCP는 IP가 보낸 데이터를 안전하고, 순서에 맞게, 오류없이 전달해주는 역할을 한다. 데이터를 보내기 전에 송신자와 수신자가 연결을 맺는 과정(3-Way Handshake)을 거친다.
데이터를 여러 조각 (세그먼트)로 나누어 보내는데, 받는 쪽에서 이 조각들을 원래 순서대로 다시 맞춰준다. 세그먼트가 중간에 없어지면, TCP는 해당 세그먼트를 다시 보내달라고 요청해서 확실하게 받도록 한다. 또 데이터가 손상되었는지도 확인해 다시 보내도록 처리하고, 받는 쪽이 데이터를 너무 빨리 받아서 성능 저하가 일어나지 않도록 속도를 조절해준다. 네트워크가 너무 혼잡할 때도 데이터 전송 속도를 줄여서 네트워크 부담을 덜어준다.
TCP는 보낸 데이터에 대해 확인 응답(ACK)을 받는다. ACK가 오지 않거나, 시간을 초과하면 데이터를 재전송한다.
UDP
UDP는 IP 위에서 작동하는 또 다른 프로토콜로 빠르고 간단하게 메시지를 보내는 데 사용된다. TCP와 달리 중간에 손상되거나 유실돼도 책임지지 않는다.
데이터를 보내기 전에 연결을 맺는 과정 없이 바로 데이터를 보낸다. 또 데이터가 제대로 도착했는지, 순서가 맞는지, 중복은 없는지 확인하거나 보장하지 않기 때문에 신뢰성이 없다. 이런 기능이 필요하다면 어플리케이션 단계에서 직접 처리해야 한다.
TCP 처럼 복잡한 확인 절차나 제어 기능이 없어 훨씬 가볍고 빠르다. 그래서 데이터가 조금 손실돼도 괜찮지만 속도가 중요한 어플리케이션에 적합하다.
TCP와 UDP 차이
| TCP | UDP | |
|---|---|---|
| 연결 | 연결을 먼저 맺어야 함 (3-Way Handshake) | 연결 없이 바로 보냄 |
| 신뢰성 | 데이터가 안전하게 도착함을 보장 (재전송, 확인 응답) | 데이터 도착 보장 안 함 (손실 가능성 있음) |
| 순서 | 데이터가 보낸 순서대로 도착함 | 데이터 순서 보장 안 함 |
| 속도 | 신뢰성 기능 때문에 상대적으로 느림 | 가볍고 단순해서 상대적으로 빠름 |
| 오버헤드 | 복잡한 기능 때문에 무거움 | 최소한의 기능만 있어 가벼움 |
| 혼잡 제어 | 네트워크 혼잡 시 속도 조절 | 혼잡 제어 기능 없음 |
참고자료
✔️ Echo Server
에코 서버는 클라이언트에서 전송받은 데이터를 그대로 서버가 클라이언트에게 전송하는 서버라고 한다. 에코 서버는 가장 단순한 형태의 서버이기 때문에 네트워크 통신의 기본 구조와 동작을 테스트하거나 학습하기 위해서 사용한다고 한다. 과제 구현을 진행할 때 우선 에코 서버로 클라이언트와 서버의 연결을 확인해보고 시작하면 좋을 것 같다.
참고자료
TCP 기반 서버 / 클라이언트에 대한 이해2 (에코 서버, TCP 내부 구조)
✔️ Client / Server
출처: https://www.cloudflare.com/en-gb/learning/serverless/glossary/client-side-vs-server-side/
인터넷 대부분은 클라이언트-서버 모델에 기반하고 있다. 사용자는 서로 직접 통신하지 않고, 중앙에 위치한 서버와 네트워크를 통해 통신해서 필요한 데이터를 받아온다.
노트북, 스마트폰, 데스크톱 같은 최종 사용자 장치들을 클라이언트(Client)라고 한다. 클라이언트는 서버에 웹페이지나 어플리케이션을 요청하고, 서버는 그 요청에 대한 응답 데이터를 제공한다.
Client-Server 모델이 사용되는 이유
서버는 일반 사용자 장치보다 훨씬 성능이 좋고 안정적이다. 서버는 상시 유지관리되고, 제어된 환경에서 운영돼 항상 가동 상태를 유지할 수 있다. 개별 서버가 고장나더라고, 다른 서버가 백업 데이터를 가지고 있어 서비스 중단을 방지할 수 있다. 사용자 장치는 꺼지거나, 분실되거나, 고장날 수 있어 다른 사용자들의 인터넷 사용에 영향을 주게 하면 안되기 때문에 Client-Server 모델이 사용된다.
참고자료
What do client side and server side mean? | Client side vs. server side | Cloudflare
✔️ Session / Connection
Session
컴퓨터 네트워크에서 세션은 시간이 제한된 양방향 연결로, 두 개 이상의 통신 장치 간의 상호작용 및 정보 교환을 가능하게 해주는 TCP/IP 프로토콜의 상위 계층에서의 개념이다. 세션이 설정되면 양방향으로 여러 개의 메시지가 오갈 수 있는 상태가 된다.
세션은 일반적으로 상태 기반(stateful)이 때문에 통신 중인 둘 중 적어도 하나는 현재 상태와 세션 이력을 저장해야 통신이 가능하다. 상태 비저장(stateless) 통신은 각각의 요청이 독립적으로 처리돼서 이전 상태 정보가 필요 없다.
연결 지향(예: TCP) 통신을 수행하려면 세션이 필수적이고, 비연결 지향(예: UDP) 통신에서도 세션 개념이 사용될 수 있지만, 단방향 전송은 세션이라 부르지 않는다.
HTTP와 세션
HTTP는 기본적으로 stateless 프로토콜이다. 따라서 세션 유지가 필요할 경우 쿠키나 세션 ID를 사용해 상태를 유지한다.
Session과 Connection 차이
| 항목 | Connection (연결) | Session (세션) |
|---|---|---|
| 정의 | 두 장치 간에 데이터를 주고받기 위한 물리적/논리적 통신 연결 | 연결 위에서 동작하는 논리적 상호작용 단위 |
| 기준 계층 | 보통 전송 계층 (TCP) | 보통 세션 계층, 또는 응용 계층에서 관리 |
| 상태 | 연결되었는지/끊어졌는지 등 연결 자체의 상태 | 사용자 인증 상태, 이전 대화 내용 등 논리적 상태 유지 |
| 지속 시간 | 데이터 전송이 끝나면 곧 종료될 수 있음 | 비교적 오래 지속, 상태를 기억하며 여러 연결을 포괄 가능 |
| 예시 | TCP 연결, 소켓 연결 | 로그인 상태, 장바구니 유지, 채팅방 활동 등 |
| 주 목적 | 데이터 전달 경로 확보 | 상태 유지와 사용자 식별 |
Connection은 물리적이거나 논리적인 상호간의 연결을 의미하는 것 같고, Session은 Connection 된 곳 위에서 동작하는 논리적인 상호작용을 의미하는 것이라고 이해했다.
참고자료
✔️ JSON
JSON은 사람이 읽고 쓰기 쉽고, 기계가 분석하고 생성하기 쉬운 구조로 이루어진 데이터 교환 형식이다. JSON은 이름/값 쌍의 모음 (Object)와 값의 순서가 있는 리스트 (Array) 두 가지 구조로 구성되어있다.
Object는 다양한 언어에서 객체, 레코드, struct, 딕셔너리, 해시 테이블, 등으로 구현된다.
Array는 대부분의 언어에서 배열, 벡터, 리스트 등으로 구현된다.
JSON 구조 표현
- 객체 (Object)
- 순서가 없는 이름/값 쌍의 집합
- 중괄호로 시작해서 중괄호로 끝남
- 각 쌍은
:으로 이름과 값을 구분, 쌍들 간에는,로 구분
- 배열 (Array)
- 순서가 있는 값들의 집합
- 대괄호로 시작해서 대괄호로 끝난다.
- 값들 간에는
,로 구분
값의 형태
- 문자열:
“hello”\를 이용해 특수 문자 이스케이프
- 숫자:
10,3.14- 8진수나 16진수는 사용하지 않는다.
- 불리언:
true,false - null:
null - 객체:
{ “key”: “value” } - 배열:
[1, 2, 3]
이런 값들은 중첩이 가능하고, 공백은 자유롭게 사용할 수 있다.
참고자료
✔️ Unicast / Boradcast / Multicast
Cast란?
Cast란 클라이언트 측에서 수신자에게 데이터(패킷 스트림)를 전송하는 방식을 의미한다. 이런 통신 방식을 통해 장치 간 데이터 교환이 이루어진다. 컴퓨터 네트워크 분야에서는 여러 형태의 캐스트 방식이 존재한다.
Unicast
Unicast란 하나의 송신자와 하나의 수신자가 참여하는 정보 전송 방식이다. 간단하게 1:1 통신이라고 할 수 있다. 데이터 전송 방식 중 가장 일반적인 방식이다.
Broadcast
Broadcast는 하나의 송신자가 네트워크의 모든 수신자에게 데이터를 전송하는 방식이다. (1:모두 통신) Broadcast는 두 가지 유형으로 나뉜다.
- Limited Broadcast
- 같은 네트워크 내 모든 장치에 패킷을 보낼 때 사용
- 목적지 주소에
255.255.255.255를 설정하면 네트워크상 모든 장치로 패킷이 전송된다.
- Direct Broadcast
- 다른 네트워크에 있는 모든 장치로 데이터를 보낼 때 사용
- 대상 네트워크의 Host ID 부분을 모두 1로 설정해 직접 브로드캐스트 주소를 생성한다.
Multicast
Multicast란 하나 이상의 송신자가 하나 이상의 수신자 그룹에게 데이터를 전송하는 방식이다. Unicast와 Broadcast 사이에 위치한 1:그룹 통신이다. 서버는 데이터 스트림을 하나만 보내고, 네트워크가 이걸 복제해 요청한 수신자들에게 전달한다.
IP Multicast는 다음과 같은 프로토콜의 지원이 필요하다.
- IGMP (Internet Group Management Protocol)
- Multicast Routing
Unicast vs Broadcast vs Multicast
| Unicast | Broadcast | Multicast | |
|---|---|---|---|
| 정의 | 1명의 송신자 → 1명의 수신자 | 1명의 송신자 → 모든 수신자 | 1명의 송신자 → 수신자 그룹 |
| 전송 방식 | 특정 수신자에게 전송 | 네트워크의 모든 수신자에게 전송 | 특정 그룹에 속한 수신자에게만 전송 |
| 주소 방식 | 고유 IP 주소 사용 | 브로드캐스트 주소 사용 (255.255.255.255) | 멀티캐스트 주소 사용 (예: 224.0.0.1) |
| 데이터 전달 | 정확한 수신자에게만 전달됨 | 모든 장치에 전달, 관심 없는 장치도 수신 | 그룹에 속하지 않은 장치는 무시 |
| 네트워크 트래픽 | 가장 적음 | 가장 많음 | 중간 정도 |
| 보안성 | 가장 안전 | 가장 낮음 | 중간 정도 |
| 예시 | 이메일, 파일 전송 | DHCP 요청, ARP 요청 | 영상 스트리밍, 온라인 게임 |
| 대상 | 단일 수신자 | 전체 네트워크 | 수신자 그룹 |
| 대역폭 사용량 | 보통 | 높음 | 보통 |
| 지연 시간 | 낮음 | 높음 | 중간 |
이번 과제에서의 고민
이번 과제에는 사용자들에게 그룹을 할당해서 채팅을 구현해야하는 내용이 있다. 이런 기능을 구현하기 위해서 Multicast가 필요하지 않을까? 하는 생각이 들었다. 아니면 Broadcast로 Multicast를 흉내내는 식으로 구현할 수도 있겠다. 그런데 찾아보니까 node에서도 multicast를 사용할 수 있다는 것 같으니 그냥 multicast로 구현하는 게 맞겠다.
참고자료
Difference between Unicast, Broadcast and Multicast in Computer Network - GeeksforGeeks
✔️ Node js net.Socket
소켓
소켓은 두 컴퓨터가 네트워크를 통해 데이터를 주고받을 수 있도록 해주는 소프트웨어 엔드포인트다. 주로 TCP 또는 UDP 프로토콜을 기반으로 동작하고, 프로세스 간 통신(IPC) 또는 네트워크 상의 통신에서 핵심 역할을 한다.
소켓은 유닉스 계열 시스템에서 운영체제가 관리하는 파일 디스크립터로 표현된다. 이건 해당 소켓에 대한 I/O 리소스를 추적하는 데 사용된다. 일반적으로 서버는 특정 포트에 대해 수신 대기중인 소켓을 생성한다. 클라이언트는 해당 포트로 연결 요청을 보내고, 서버는 이를 수라함으로써 새로운 소켓을 생성해 해당 클라이언트와 통신을 시작한다. 이때 원래의 리스닝 소켓은 여전히 새로운 연결을 기다리는 역할을 한다.
소켓은 TCP 소켓과 UDP 소켓을 정할 수 있다.
Node.js에서의 소켓 관리
Node.js는 싱글 스레드 기반의 이벤트 루프를 사용한다. 소켓에서 읽기/쓰기와 같은 I/O는 블로킹 없이 백그라운드에서 처리되며, 완료되었을 때 이벤트로 알린다.
새 연결마다 소켓 객체가 생성되고, 해당 소켓에서 data, end, error 등의 이벤트를 통해 데이터를 비동기적으로 처리한다.
각 소켓은 운영체제의 리소스를 사용하고, 파일 디스크립터 수에 제한이 있기 때문에 무제한으로 연결을 유지할 수는 없다.
부하가 높을 때 발생할 수 있는 문제
| 문제 | 설명 |
|---|---|
| 파일 디스크립터 고갈 | 연결 수가 많아지면 파일 디스크립터 수가 한계를 넘어서고, 더 이상 소켓을 열 수 없어 EMFILE 오류가 발생할 수 있다. |
| 네트워크 스택 병목 | 커널 수준의 네트워크 처리 속도가 제한되어 있어 패킷 손실이나 지연이 발생할 수 있다. |
| 이벤트 루프 포화 | 이벤트 루프에서 동기 코드나 처리 지연이 많으면 전체 응답 속도가 느려지고 병목이 발생한다. |
| 메모리 사용 증가 | 각 소켓이 메모리를 점유하므로, 연결이 많아질수록 메모리 사용량도 커진다. |
| CPU 사용량 증가 | 요청 처리 로직에 따라 CPU 사용량이 급증해 전체 처리량에 영향을 줄 수 있다. |
고부하 대응 전략
- 수평적 확장
- 시스템 한계 상향 조정
- 리소스 효율화
- 모니터링 및 알림 시스템
단일 머신에서의 수평 확장
Node.js는 기본적으로 싱글 스레드이지만, cluster 모듈을 통해 여러 개의 프로세스를 생성하여 멀티 코어 활용이 가능하다. 이 방식으로 단일 머신에서의 다중 인스턴스 실행을 통해 수평적 확장을 할 수 있다.