정보 제공 상태 코드 :: 1xx

HTTP 상태 코드 중에서 잘 안 쓰이지만 존재하는 게 바로 1xx (Informational) 범주예요.

---

1. 1xx 상태 코드란?

• 정보 제공용 상태 코드
• 클라이언트 요청을 서버가 최종 응답 전, 중간 단계에서 알림 으로 보내는 것
• 요청 자체는 정상적이고, 추가 동작이 계속 진행 중이라는 의미

---

2. 주요 1xx 코드

🔹 100 Continue

• 클라이언트가 큰 데이터를 보낼 때 사용
• 클라이언트가 Expect: 100-continue 헤더를 보냈다면,
  서버는 100 Continue로 "좋아, 본문(body) 보내도 돼"라고 신호 줌
• 본문을 굳이 전송하지 않아도 되는 상황이면 클라이언트가 낭비를 피할 수 있음

---

🔹 101 Switching Protocols

• 서버가 프로토콜을 변경했음을 알림
• 예: HTTP/1.1 → WebSocket ㅣ HTTP/2 등으로 업그레이드

---

🔹 102 Processing (WebDAV 확장)

• 서버가 요청을 받았고 처리 중이지만, 아직 최종 응답을 못 주는 경우
• 클라이언트가 타임아웃으로 착각하지 않도록 중간 알림

---

🔹 103 Early Hints

• 서버가 최종 응답 전에 **리소스 힌트(Preload, Preconnect)**를 미리 클라이언트에 전달
• 브라우저는 HTML 본문을 다 받기 전에 필요한 CSS, JS, 이미지 로드를 미리 시작 가능

---

3. 특징

• 임시적 / 중간 응답 → 최종 응답(2xx, 3xx, 4xx, 5xx)이 반드시 뒤따라옴
• 실제 API 개발에서는 잘 안 쓰이고,
  주로 HTTP 최적화, 대용량 업로드, 프로토콜 업그레이드 같은 특수 상황에서만 사용

---

✅ 정리

• 1xx = 정보성 상태 코드 (중간 알림)
• 대표 코드:
  • 100 Continue → 본문 전송해도 됨
  • 101 Switching Protocols → 프로토콜 변경 (예: WebSocket)
  • 102 Processing → 처리 중, 아직 결과 없음
  • 103 Early Hints → 필요한 리소스 미리 알려줌

---

 

101 Switching Protocols 상태 코드와 Upgrade 헤더의 관계를 정확히 이해하면 훨씬 명확해져요.

---

1. 101 Switching Protocols 개념

• 클라이언트가 프로토콜 업그레이드 요청을 보냈을 때,
  서버가 이를 수락하고 "좋아, 이제부터 다른 프로토콜로 통신하자"라는 신호를 주는 상태 코드예요.

즉,

• 요청: "나 HTTP 쓰고 있는데, WebSocket으로 바꾸고 싶어"
• 응답: "좋아, WebSocket으로 바꾸자" → 101 Switching Protocols

 

---

2. Upgrade 헤더

• 클라이언트 → 서버: Upgrade 헤더로 "어떤 프로토콜로 바꾸고 싶은지" 제안
• 서버 → 클라이언트: Upgrade 헤더로 "어떤 프로토콜로 바꿨는지" 확정

예시 (WebSocket 업그레이드)

클라이언트 요청

 

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

서버 응답

 

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

---

3. 변경 전 프로토콜은 어떻게 알 수 있나?

• 변경 전 프로토콜은 항상 HTTP예요.
• 왜냐하면 업그레이드 요청(Upgrade 헤더)이 HTTP 요청 안에서만 가능하기 때문이죠.
• 즉, “HTTP로 통신하다가 → 다른 프로토콜(WebSocket, HTTP/2, TLS 등)로 바꾼다”라는 과정이에요.

---

4. 정리

• 101 Switching Protocols = 서버가 프로토콜 업그레이드 수락
• Upgrade 헤더 = 업그레이드 대상 프로토콜 명시
• 변경 전 프로토콜 = HTTP (항상 HTTP 요청으로 시작)
• 변경 후 프로토콜 = Upgrade 헤더 값 (예: websocket, h2c, TLS/1.3 등)

---

👉 쉽게 말하면:

• “HTTP로 시작해야만 업그레이드 협상이 가능”
• 101은 **“HTTP는 이제 그만, 앞으로는 네가 원하는 새 프로토콜로 얘기하자”**라는 응답

---

 

Connection 헤더는 HTTP에서 꽤 중요한 역할을 하는데, 많이들 헷갈려해요. 차근차근 설명해 드릴게요.

---

1. Connection 헤더란?

HTTP/1.1 기준에서,
👉 클라이언트와 서버 간의 TCP 연결을 어떻게 유지할지 / 특정 헤더가 현재 연결에만 적용되는지를 지정하는 헤더예요.

---

2. 주요 역할

(1) 연결 유지 여부 제어

• HTTP/1.0에서는 기본이 단일 요청-응답 후 연결 종료였어요.
• HTTP/1.1부터는 기본이 지속 연결(persistent connection) → 여러 요청/응답을 같은 TCP 연결에서 처리 가능.

Connection 헤더로 이를 명시적으로 제어할 수 있어요:

• Connection: keep-alive → 연결 유지 (여러 요청/응답 처리 가능)
• Connection: close → 응답 후 TCP 연결 닫음

---

(2) Hop-by-Hop 헤더 지정

• 일부 헤더는 중간 프록시/게이트웨이를 거치지 않고, 오직 현재 연결에서만 의미가 있음
• 이런 헤더들을 Connection에 나열하면, 그 헤더는 다음 홉(hop)으로 전달되지 않음

예:

Connection: Upgrade
Upgrade: websocket

• 여기서 Upgrade 헤더는 현재 연결에서만 의미 있음 → 프록시가 다른 서버로 전달할 필요 없음

---

3. 예시

1) 연결 유지

요청

GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

응답

HTTP/1.1 200 OK
Connection: keep-alive

→ 같은 TCP 연결에서 여러 요청 가능

---

2) 프로토콜 업그레이드 (WebSocket)

요청

 

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

응답

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

→ 이후부터는 WebSocket 프로토콜 사용

---

4. 정리

• Connection 헤더 = 현재 TCP 연결 제어 + Hop-by-Hop 헤더 지정
• 주요 값:
  • keep-alive → 연결 유지
  • close → 연결 닫음
  • Upgrade → 프로토콜 업그레이드 요청

---

👉 한마디로, Connection 헤더는 이 TCP 연결을 어떻게 다룰지, 어떤 헤더가 이 연결에만 적용되는지를 알려주는 용도예요.

 

---

 

HTTP/1.1부터는 “연결 유지(persistent connection)”가 기본 동작이라서

사실 Connection: keep-alive를 굳이 쓸 필요는 없어요.

---

🔹 HTTP/1.0 vs HTTP/1.1 차이

HTTP/1.0

• 기본: 요청 1개 → 응답 1개 → 연결 종료
• 지속 연결이 필요하면 명시적으로라고 적어야 했음.
•  
  Connection: keep-alive

---

HTTP/1.1

• 기본: 연결 지속이 자동으로 활성화(persistent)
• 여러 요청/응답을 같은 TCP 연결에서 처리 가능 (파이프라이닝도 가능)
• 연결을 끊고 싶을 때만라고 명시해야 함.
•  
  Connection: close

즉, 1.1에서는 keep-alive를 안 써도 계속 연결 유지돼요.

---

🔹 그런데 왜 지금도 Connection: keep-alive를 볼까?

1. 하위 호환성
   • 여전히 HTTP/1.0 클라이언트/프록시가 있을 수 있기 때문에, 안전하게 keep-alive를 적는 경우가 있음.
2. 명시적 의도 표시
   • 기본 동작이지만 “연결 유지할 거야”라는 의도를 분명히 하려고 서버/클라이언트에서 넣기도 함.
3. 중간 장비(프록시, 로드밸런서) 고려
   • 일부 프록시/로드밸런서는 Connection: keep-alive가 있어야 연결을 유지하기도 함.

---

✅ 정리

• HTTP/1.0: 기본이 비지속 연결, Connection: keep-alive 필요
• HTTP/1.1: 기본이 지속 연결, Connection: close로만 끊을 수 있음
• 그래서 HTTP/1.1에서는 사실상 keep-alive는 불필요하지만,
  하위 호환성이나 의도 표시 때문에 관습적으로 여전히 자주 쓰임

---

👉 결론:
질문 주신 대로 HTTP/1.1에서는 굳이 명시할 필요 없다가 맞습니다.