🌐 모든 통신의 근본: Request - Response

우리가 인터넷을 쓰는 거의 모든 순간, 사실 하나의 단순한 구조가 반복됩니다.

클라이언트가 요청을 보낸다.  
서버는 그 요청을 파싱한다.  
서버는 요청을 처리한다.  
서버는 응답을 보낸다.  
클라이언트는 응답을 파싱하고 소비한다.

이 구조는 단순하지만 강력합니다. HTTP, DNS, SSH, RPC, SQL, REST API, GraphQL, SOAP… 우리가 쓰는 거의 모든 기술이 이 틀 안에서 작동합니다.

---

🧪 직접 보기: curl로 HTTP 요청 해부하기 간단한 명령 하나로 이 과정을 눈으로 직접 볼 수 있습니다.

curl -v --trace out.txt http://google.com

• -v: 요청과 응답의 헤더를 터미널에 출력
• –trace out.txt: 내부 송수신 로그를 파일로 저장

---

🧩 로그 분석: 실제 요청 흐름 out.txt에는 다음과 같은 흐름이 기록됩니다:

== Info: Host google.com:80 was resolved.
== Info: IPv4: 142.250.76.142
== Info: Trying 142.250.76.142:80...
== Info: Connected to google.com (142.250.76.142) port 80
== Info: using HTTP/1.x

➤ 클라이언트 → 서버 요청

=> Send header
GET / HTTP/1.1
Host: google.com
User-Agent: curl/8.13.0
Accept: */*

➤ 서버 → 클라이언트 응답

<&#x3D; Recv header
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset&#x3D;UTF-8
...
Content-Length: 219

➤ HTML 응답 본문

301 Moved
301 Moved
The document has moved here.

서버는 요청을 받고, 우리가 보낸 헤더를 기반으로 판단하여 HTTP 301 리디렉션 응답을 보내줍니다. 이 과정 하나만으로도 요청-응답 모델의 모든 단계가 담겨 있습니다.

---

• ✅ JSON: 구조 단순, 파싱 빠름
• ❌ XML: 구조 복잡, 파싱 비용 큼 → 실시간 API에선 비효율

---

• Request - Response는 모든 네트워크 통신의 기본 구조다.
• curl을 활용하면 이 과정을 직접 확인할 수 있다.
• HTTP 헤더, 상태 코드, 응답 본문을 읽는 연습은 모든 개발자에게 유익하다.
• 효율적인 통신을 위해서는 JSON을 기본 포맷으로 고려하자.

---

이처럼 복잡한 시스템도 결국 단순한 요청-응답의 반복입니다. 그 흐름을 정확히 읽는 눈을 가지면, 기술이 단순하게 보입니다.