Web

글 21개

주소창 한 줄의 여정 - 밑단을 잇는다

Network · HTTP

주소창 한 줄의 여정 - 밑단을 잇는다

주소창에 한 줄 치고 엔터를 누르면, 이름을 주소로 바꾸고 기계를 찾고 문을 두드리고 자물쇠를 채운 뒤에야 HTTP가 오간다. 지금까지의 밑단을 통째로 이어 그 여정을 따라가며, 어디서 느려지는지까지 짚고 시리즈를 닫는다.

·패킷은 어떻게 도착하나 8편
내 컴퓨터는 왜 직접 안 닿나 - NAT

Network · NAT

내 컴퓨터는 왜 직접 안 닿나 - NAT

집 안 기기 수십 개가 공인 IP 하나를 나눠 쓴다. 공유기가 나갈 때 주소를 바꿔치기하고 돌아올 때 되돌리는 NAT 덕이다. 이게 IPv4 부족을 버티게 하는 동시에, 왜 밖에서 내 기계를 직접 못 부르는지도 설명한다.

·패킷은 어떻게 도착하나 7편
그냥 던진다 - UDP

Network · UDP

그냥 던진다 - UDP

TCP의 악수와 재전송은 신뢰성을 주지만 그만큼 느리다. UDP는 그 안전장치를 다 버리고 그냥 던진다. 도착 보장도 순서 보장도 없는 대신 빠르고 단순한 이 방식이, 왜 영상·게임·HTTP/3에 맞는지.

·패킷은 어떻게 도착하나 6편
안 끊기고 순서대로 오게 - TCP

Network · TCP

안 끊기고 순서대로 오게 - TCP

인터넷은 패킷을 잃기도 뒤섞기도 한다. 그런데 웹페이지는 한 글자도 안 틀리고 순서대로 도착한다. 그 신뢰성을 맡는 TCP - 먼저 악수로 연결을 맺고, 조각마다 받았다는 확인을 주고받으며, 잃은 건 다시 보낸다.

·패킷은 어떻게 도착하나 5편
한 기계 안에서 어느 프로세스로 - 포트

Network · Port

한 기계 안에서 어느 프로세스로 - 포트

IP 주소는 기계까지만 데려다준다. 그 기계 안에는 웹 서버, DB, SSH가 함께 도는데, 도착한 패킷이 어느 프로세스로 가야 하나. 그걸 정하는 문 번호가 포트다. 소켓과 파일 디스크립터로 어떻게 프로세스에 이어지는지까지.

·패킷은 어떻게 도착하나 4편
이름을 주소로 바꾼다 - DNS

Network · DNS

이름을 주소로 바꾼다 - DNS

우리는 142.250.72.14가 아니라 google.com을 친다. 그 이름을 IP 주소로 바꿔주는 게 DNS다. 이름을 뒤에서부터 단계로 찾아 내려가는 조회, 그리고 캐싱과 TTL이 왜 DNS 변경을 늦게 퍼지게 하는지.

·패킷은 어떻게 도착하나 3편
패킷은 어느 기계로 가나 - IP 주소

Network · IP

패킷은 어느 기계로 가나 - IP 주소

편지를 보내려면 주소가 필요하듯, 패킷도 목적지 기계의 주소가 필요하다. IP 주소가 무엇이고, 패킷이 어떻게 라우터를 하나씩 건너 목적지까지 가는지 - 라우터가 전체 길을 모르고도 배달이 되는 이유.

·패킷은 어떻게 도착하나 2편
HTTP 밑에 무엇이 있나 - 네트워크 계층

Network · Layers

HTTP 밑에 무엇이 있나 - 네트워크 계층

HTTP는 네트워크의 맨 위 한 겹일 뿐이다. 그 밑에 데이터를 실어 나르는 TCP가 있고, 또 그 밑에 기계를 찾아가는 IP가 있다. 봉투 안의 봉투처럼 층으로 쌓인 이 구조를 보면, 왜 각 층을 따로 갈아끼울 수 있는지가 풀린다.

·패킷은 어떻게 도착하나 1편
버저닝과 하위 호환

API · Versioning

버저닝과 하위 호환

v2를 냈는데 v1을 못 내리는 상황을 어떻게 피하나. 깨지 않고 바꾸는 방법이 먼저이고, 버전을 가르는 건 그다음이다.

·API 설계 7편
GraphQL - 필요한 것만 받는다

API · GraphQL

GraphQL - 필요한 것만 받는다

화면 하나에 API를 다섯 번 부르는 문제를 GraphQL은 어떻게 다르게 푸나. REST와의 차이와 그 대가만 본다.

·API 설계 6편
JSON - 왜 이게 표준이 됐나

API · JSON

JSON - 왜 이게 표준이 됐나

타입이 여섯 개뿐인 형식이 어떻게 API의 기본이 됐나. 큰 정수·날짜·null이라는 세 함정과 스키마 없음의 대가.

·API 설계 5편
상태 코드와 에러 응답

API · REST

상태 코드와 에러 응답

200 OK인데 본문에 error가 있는 응답은 왜 문제인가. 상태 코드를 고르는 기준과 에러 본문을 한 벌로 통일하는 법.

·API 설계 4편
Endpoint 설계

API · REST

Endpoint 설계

같은 목록을 주는 URL이 여럿이 되지 않게 하는 법. 컬렉션과 단건, 중첩 기준, 필터·정렬·페이징 파라미터와 목록 응답 모양을 정한다.

·API 설계 3편
REST - 자원으로 말한다

API · REST

REST - 자원으로 말한다

/getUserList는 왜 REST가 아닌가. 동사를 URL에서 걷어내고 자원과 메서드로 말하는 방식을 잡는다.

·API 설계 2편
API는 약속이다

API · Design

API는 약속이다

내부 코드는 언제든 고치지만 공개한 API는 남이 이미 그 모양에 맞춰 코드를 짜뒀다. API를 계약으로 보는 관점을 잡는다.

·API 설계 1편
WebSocket - 요청 없이 받는다

WebSocket · HTTP

WebSocket - 요청 없이 받는다

서버가 먼저 말을 걸 수 없다는 전제를 뒤집는 방법들. 폴링부터 SSE, 그리고 프로토콜을 바꾸는 WebSocket까지.

·HTTP는 어떻게 오가나 6편
HTTPS - 무엇을 감추고 무엇을 못 감추나

HTTPS · TLS

HTTPS - 무엇을 감추고 무엇을 못 감추나

자물쇠가 떴다고 다 가려진 게 아니다. HTTPS가 실제로 감추는 것과, 감싸고도 그대로 노출되는 것을 가른다.

·HTTP는 어떻게 오가나 5편
캐시 - 안 보내는 게 가장 빠르다

HTTP · Web

캐시 - 안 보내는 게 가장 빠르다

배포했는데 사용자 화면이 안 바뀐다. 그 사고에서 출발해 Cache-Control·ETag·조건부 요청이 무엇을 정하는지 본다.

·HTTP는 어떻게 오가나 4편
연결을 매번 새로 맺지 않는다

HTTP · Web

연결을 매번 새로 맺지 않는다

요청을 보내려면 먼저 연결부터 맺어야 한다. 그 준비 비용을 줄이려는 시도가 HTTP 버전을 올려온 이유다.

·HTTP는 어떻게 오가나 3편
상태를 안 갖는다는 것

HTTP · Web

상태를 안 갖는다는 것

서버는 방금 로그인한 사람도 다음 요청에서 못 알아본다. 그 불편을 일부러 감수한 이유와, 그래서 상태를 어디에 두게 됐는지.

·HTTP는 어떻게 오가나 2편
요청과 응답 - 한 번의 왕복에 무엇이 오가나

HTTP · Web

요청과 응답 - 한 번의 왕복에 무엇이 오가나

주소창에 한 줄 쳤을 때 실제로 오가는 건 글자 몇 줄이다. 그 글자가 어떻게 생겼고 어디를 지나는지 본다.

·HTTP는 어떻게 오가나 1편