웹 요청 정복 : HTTP 구조부터 에러 코드까지

들어가기 전

웹 개발의 시작은 HTTP(HyperText Transfer Protocol)를 이해하는 것에서부터 시작됩니다. HTTP는 클라이언트와 서버가 서로 "말"을 주고받는 약속이자 규칙인데요, 이번 글에서는 HTTP의 기본 구조와 동작 원리, 그리고 웹 요청-응답 과정에서 마주하게 되는 다양한 상태 코드(status code)를 함께 살펴보겠습니다. 간단한 예시와 다이어그램을 통해 HTTP가 어떻게 동작하는지 감을 잡고, 에러 상황별 발생 원인과 해결책을 이해하면 웹 서비스를 설계·개발·디버깅할 때 많은 도움이 될 거예요.

---

1. HTTP의 구조와 동작 원리

1-1. 클라이언트-서버 모델

HTTP는 웹 브라우저(클라이언트)와 웹 서버가 데이터를 주고받는 통신 규약입니다. 클라이언트가 서버에 요청(request)을 보내면, 서버는 그에 대한 응답(response)을 돌려줍니다.

1-2. 통신 과정 요약

아래 다이어그램은 DNS 조회부터 TCP 연결, HTTP 요청·응답, 그리고 연결 종료 또는 재사용까지의 전체 흐름을 보여줍니다.

1. DNS 조회

   • 도메인 이름(예: www.example.com)을 IP 주소로 변환하기 위해 DNS 서버에 질의합니다.

2. TCP 연결

   • 클라이언트와 서버 간에 TCP 3-way 핸드셰이크(SYN→SYN-ACK→ACK)를 수행하여 안정적인 전송 채널을 만듭니다.

3. HTTP 요청 (GET /index.html HTTP/1.1 예시)

   • 요청 메시지 구조:

     • Start Line: 프로토콜 버전, 상태코드, 상테 메시지 (GET /index.html HTTP/1.1)
     • Headers: 응답 메타 정보 (예: Host: www.example.com, User-Agent: ..., Accept: ...)
     • Empty Line: 헤더와 Body 구분
     • Body: POST나 PUT 요청 시 전송할 데이터 (HTML, JSON 등)

4. HTTP 응답 (HTTP/1.1 200 OK 예시)

   • 서버가 요청을 처리한 뒤 응답 메시지를 반환하고, Body에 리소스(HTML, JSON 등)를 담습니다.

5. 연결 종료/재사용

   • 기본적으로 HTTP/1.1은 Connection: keep-alive로 설정되어 동일한 TCP 연결을 재사용합니다.
   • 필요 시 Connection: close로 연결을 종료하여 리소스를 해제합니다.

---

2. 상태 코드(Status Code)별 이해

2.1 2xx: 성공 응답

서버가 클라이언트의 요청을 성공적으로 처리했음을 의미합니다.

코드	설명	예시 상황 & 해결책
200 OK	요청 성공	예시: GET 요청 후 정상 리소스 반환 해결: 클라이언트 로직 검증, API 문서 확인
201 Created	리소스 생성	예시: POST /users로 신규 사용자 생성 해결: Location 헤더의 새 리소스 확인
202 Accepted	비동기 처리	예시: 대용량 작업 큐 등록 해결: 상태 체크 API 폴링 또는 Webhook 활용
204 No Content	본문 없는 성공	예시: DELETE /items/123 삭제 완료 해결: UI 리스트 갱신 반영

2.2 3xx: 리다이렉트

클라이언트를 다른 URL로 안내합니다.

코드	설명	예시 상황 & 해결책
301 Moved Permanently	영구 이동	예시: 도메인 A → B 리다이렉트 해결: 캐시 삭제, 검색엔진 재색인 요청
302 Found	임시 이동	예시: 유지보수 페이지 임시 안내 해결: 원래 URL 자동 재접근
303 See Other	POST→GET 리디렉션	예시: 폼 제출 후 결과 페이지 이동 해결: 클라이언트 GET 요청 수행
307 Temporary Redirect	임시 이동(메서드 유지)	예시: A/B 테스트용 임시 서버 해결: 원 메서드 그대로 재요청
308 Permanent Redirect	영구 이동(메서드 유지)	예시: API 버전 업그레이드 영구 리다이렉트 해결: 클라이언트 코드 업데이트

2.3 4xx: 클라이언트 에러

클라이언트의 잘못된 요청으로 인해 처리할 수 없음을 나타냅니다.

코드	설명	예시 상황 & 해결책
400 Bad Request	잘못된 요청	예시: 필수 필드 누락, 잘못된 JSON 해결: 요청 데이터 검증 추가
401 Unauthorized	인증 필요	예시: 토큰 미제공/만료 해결: 로그인 후 토큰 발급/갱신
403 Forbidden	권한 없음	예시: 관리자 리소스 무단 접근 해결: 권한 정책 검토
404 Not Found	리소스 없음	예시: 잘못된 URL/삭제된 리소스 해결: URL/ID 확인
429 Too Many Requests	요청 과다	예시: 단시간 내 과도한 호출 해결: Retry-After 로직 도입

2.4 5xx: 서버 에러

서버 내부 문제로 요청을 처리하지 못할 때 발생합니다.

코드	설명	예시 상황 & 해결책
500 Internal Server Error	서버 일반 오류	예시: 예외 미처리 해결: 로그 확인, 예외 처리 보강
502 Bad Gateway	게이트웨이 오류	예시: 프록시 문제 해결: 상위 서버 상태 점검
503 Service Unavailable	서비스 중단/과부하	예시: 유지보수/스케일링 부족 해결: 오토스케일링 설정, 안내 페이지 제공
504 Gateway Timeout	게이트웨이 타임아웃	예시: 응답 지연 해결: 타임아웃 설정 최적화

---

이번 글에서는 HTTP의 기본 구조와 동작 원리, 그리고 상태 코드별 의미와 해결 방법을 살펴보았습니다. 다음 포스트에서는 인증·인가와 세션 관리에 대해 자세히 다뤄보겠습니다.

---

부록: TCP 3-way 핸드셰이크란?

TCP 연결을 시작하기 전에 클라이언트와 서버가 서로 신뢰성 있는 채널을 마련하는 과정을 TCP-3-way 핸드셰이크라고 합니다. 이 과정을 통해 각 측이 제대로 준비됐는 지 확인하고, 데이터 전송의 순서를 관리할 초기 시퀀스 번호를 교환합니다.

1. 클라이언트 -> 서버 : SYN (seq = x)

• 클라이언트가 새로운 연결 요청을 의미하는 SYN(Synchronize) 플래그를 켠 TCP 패킷을 보냅니다.
• seq=x는 클라이언트가 사용할 첫 번째 데이터 바이트 번호를 의미합니다.

2. 서버 -> 클라이언트 : SYN-ACK (seq=y, ack=x+1)

• 서버는 클라이언트 요청을 수락한다는 의미로 SYN과 ACK(Acknowledgment) 플래그를 모두 켠 패킷으로 응답합니다.
• seq=y 는 서버가 사용할 첫 번째 데이터 바이트 번호,
  
  ack=x+1은 클라이언트의 SYN에 대한 확인 응답 번호입니다.

3. 클라이언트 -> 서버 : ACK (ack = y+1)

• 클라이언트는 서버의 SYN-ACK에 대한 확인 응답으로 ACK 플래그를 켠 패킷을 보냅니다.
• ack=y+1은 서버가 보낸 SYN에 대한 확인 응답 번호입니다.

왜 3-way 핸드셰이크가 필요할까요

• 양방향 준비 확인 : 단방향 SYN/ACK만으로는 한쪽이 준비되지 않을 수 있기 때문에, 양쪽이 서로 준비되었음을 모두 확인합니다.
• 시퀀스 번호 설정 : 이후 전송할 데이터의 순서를 맞추기 위해 초기 시쿼스 번호를 교환합니다.
  -중복 연결 방지 : 이전 세션의 잘못된 패킷(지연된 SYN 등)이 새 연결로 오인되는 것을 방지합니다.

Client                  Server
   | --- SYN, seq=x ---> |
   | <--- SYN-ACK ------ |
   |     seq=y, ack=x+1  |
   | --- ACK, ack=y+1--->|
   |                     |
 [이제 데이터 전송 가능]