HTTP와 웹 통신 기초

1. HTTP란?

HTTP(HyperText Transfer Protocol)는 웹 브라우저와 서버가 서로 데이터를 주고 받을 때 사용하는 규칙(프로토콜) 입니다.

• 사용자는 브라우저에서 주소를 입력하거나 버튼을 클릭
• 브라우저는 서버에게 요청(request)을 전송
• 서버는 요청을 처리한 후, 응답(response)을 전송

이때 “요청과 응답을 어떤 형식으로 주고받을지”를 정해놓은 약속이 바로 HTTP 입니다.

---

2. HTTP 메서드와 Idempotent

HTTP 요청에는 “이 요청으로 무엇을 하고 싶은지”를 나타내는 동사가 있습니다.

이것이 바로 HTTP 메서드(Method) 입니다.

2-1. 자주 쓰는 HTTP 메서드

GET

• 서버의 리소스를 조회할 때 사용
• ex) 게시글 목록 가져오기, 특정 글 상세 조회 등

POST

• 서버에 새로운 리소스를 생성할 때 사용
• ex) 회원가입, 글 작성 등

PUT

• 리소스를 통째로 수정(치환)할 때 사용
• ex) 게시글 전체를 새로운 내용으로 바꾸기

PATCH

• 리소스를 부분적으로 수정할 때 사용
• ex) 게시글 제목 수정

DELETE

• 리소스를 삭제할 때 사용

2-2. Idempotent(멱등성) 이란?

멱등(Idempotent) 이라는 “개념은 같은 요청을 여러 번 보내도 결과가 달라지지 않는 성질”을 의미합니다.

예를 들어 DELETE/posts/1 요청이 오는 경우

• 첫 번째 요청: 1번 글 삭제
• 두 번째 요청: 이미 글이 삭제된 상태라 삭제할 대상이 없음. 결과적으로 서버의 상태는 “삭제된 상태”로 변하지 않음

⇒ 즉, 여러 번 요청해도 최종 상태가 같습니다. 이런 메서드는 멱등하다고합니다.

 

보통 POST를 제외한 다른 메서드들은 멱등하다고 합니다.

• GET /posts/1을 10번 호출해도 조회만 하므로 데이터는 변하지 않음
• POST /payments를 10번 호출하면 결제가 10번 일어날 수 있음

HTTP 기준 POST를 제외한 메서드는 멱등하게 설계되어 있습니다.
하지만 실제 서버 구현에서 GET 호출마다 조회수를 증가시키거나, DELETE 시마다 로그를 추가하면 멱등성이 깨질 수 있습니다.

즉, 멱등성은 메서드 자체의 특징이라기보다, 같은 요청이 서버 상태를 변화시키지 않도록 구현하는 것이 핵심입니다.

 

왜 멱등성이 중요할까요?

• 네트워크 장애로 인해 요청이 중복될 수 있음
• 서버 또는 클라이언트에서 재시도 로직을 넣을 수 있음

⇒ 이때 메서드를 여러 번 호출해도 되는지를 판단하는 기준이 멱등성입니다.

---

3. HTTP/1.1, HTTP/2, HTTP/3의 차이

HTTP는 버전이 올라가면서 성능과 효율이 개선되었습니다.

3-1. HTTP/1.1

1. 텍스트 기반 프로토콜
   •   요청/응답 헤더가 사람이 읽을 수 있는 텍스트 형태입니다.
2. 기본적으로 Keep-Alive 지원
   •   하나의 TCP 연결을 여러 요청에 재사용할 수 있습니다.
3. 단점: HOL(Head Of Line) Blocking
   •   브라우저가 여러 리소스(HTML, CSS, JS, 이미지 등)를 받아와야 할 때 한 연결에서 요청을 순서대로 처리하다 보니 앞 요청이 느려지면 뒤 요청도 같이 느려지는 문제가 있습니다.
   •   이 때문에 브라우저는 보통 도메인당 여러 개의 TCP 연결을 열어 해결하려 했습니다.

3-2. HTTP/2

HTTP/2는 한 연결로 여러 요청을 동시에 처리하는 것에 초점을 맞춘 버전입니다.

1. Binary 프로토콜
   •   텍스트가 아닌 이진(binary) 형식으로 통신합니다.
   •   파싱 속도가 빠르고 효율적입니다.
2. Multiplexing(다중화)
   •   하나의 TCP 연결 안에서 여러 요청과 응답을 동시에 처리할 수 있습니다.
   •   HTTP/1.1에서 발생하던 HOL Blocking 문제가 완화됩니다.
3. Header Compression
   •   매 요청마다 큰 헤더를 압축해서 전송합니다.
   •   네트워크 사용량이 줄어듭니다.
4. Server Push
   •   서버가 클라이언트가 요청하지 않은 리소스를 먼저 보내줄 수 있는 기능입니다.
   •   실제로 캐시, 중복 문제 등의 이유로 많이 사용되지는 않습니다.

3-3. HTTP/3

HTTP/3는 TCP 대신 QUIC(UDP 기반 프로토콜)을 사용하여 연결 성능을 더 개선한 버전입니다.

1. TCP가 아닌 QUIC 사용
   •   TCP의 연결 설정, 혼잡 제어, 재전송 등에서 오는 지연을 줄이기 위한 목적입니다.
2. 빠른 연결 설정
   •   TLS와 연결 설정을 합쳐 더 빠르게 통신을 시작할 수 있습니다.
     •    TLS는 'Transport Layer Security'의 약자로, 인터넷 상의 통신 데이터를 암호화하여 보호하는 보안 프로토콜
3. HOL Blocking 문제 추가
   •   TCP는 패킷이 중간에 유실되면 해당 패킷이 재전송될 때까지 뒤에 온 패킷들도 대기해야 합니다.
   •   QUIC은 스트림 단위로 처리되기 때문에 하나의 스트림에서 패킷이 유실되어도 다른 스트림에 영향을 덜 줍니다.

---

4. Keep-Alive란?

HTTP/1.0 시절 요청이 오면 TCP 연결을 생성하고, 응답이 완료되면 TCP 연결을 종료시키는 과정을 반복했습니다. 하지만 TCP 연결을 열고 닫는 것은 비용이 많이 듭니다.

그래서 등장한 것이 Keep-Alive입니다. 하나의 TCP 연결을 여러 요청에서 재사용합니다.

 

TCP 연결 생성에는 3-way handshake가 필요합니다. 이 과정을 반복하면 지연 시간이 늘어나고 부하가 커집니다.

그래서 Keep-Alive를 사용하면 한 번 연결한 후 여러 HTTP 요청을 같은 연결로 보낼 수 있으므로 성능이 향상됩니다.

---

5. HTTP vs HTTPS

HTTP는 암호화되지 않은 평문 통신입니다. 중간에서 패킷을 가로채면, 요청 내용과 응답 내용을 그대로 볼 수 있습니다.

HTTPS는 HTTP 위에 TLS(옛 SSL) 계층을 올려 암호화된 통신을 합니다. 중간에서 패킷을 가로채더라도 암호화 되어있기 때문에 내용을 해석할 수 없습니다.

 

TLS Handsahke

출처: 나무위키

1. Client Hello
   • 클라이언트에서 서버에게 여기에는 클라이언트에서 사용 가능한 TLS 버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보를 포함해서 전송
2. Server Hello
   • 서버가 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보를 포함해 응답
   • 인증서 전송
3. 인증서 검증
   • 클라이언트는 서버가 보낸 인증서를 확인하고, 신뢰할 수 있는 인증 기관에서 발급받은 것인지 검증
4. 대칭키 생성 및 공유
   • 클라이언트와 서버는 최종적으로 대칭키(같은 키)를 공유
   • 이 키로 이후의 HTTP 요청/응답을 암호
5. 암호화된 데이터 전송 시작

---

6. CORS(Cross-Origin Resource Sharing) 란?

브라우저는 보안 상 이유로 다른 출처로의 요청에 제한을 둡니다. 여기서 출처는 다음 3가지를 합친 것입니다.

• 프로토콜 (http/https)
• 도메인 (example.com)
• 포트 (:8080 등)

이 세 가지 중 하나라도 다르면 다른 출처로 간주합니다.

 

그런데 실제 웹 서비스에는 다른 출처로 요청해야 하는 경우가 많습니다.

그래서 CORS는 보안 때문에 차단된 cross-origin 요청을 브라우저가 허용할 수 있도록 서버가 ‘이 요청은 허용해도 된다’는 정보를 명시적으로 제공하는 메커니즘 입니다.

 

6-1. CORS 에러가 발생하는 이유

CORS 에러가 발생하는 이유는 브라우저가 응답을 막기 때문입니다.

흐름을 다시 정리해보면,

1. 프론트가 서버에 요청을 보냅니다.
2. 서버는 정상적으로 응답을 보냈을 수 있습니다.
3. 하지만 응답 헤더에 Access-Control-Allow-Origin: http://localhost:3000 같은 허용 증거가 없다면,
4. 브라우저가 응답 결과를 자바스크립트에 전달하지 않습니다.

그래서 개발자 도구에서는 CORS 에러가 떴는데, 서버 로그는 멀쩡한 상황이 많이 발생합니다.

6-2. CORS 해결 방법

CORS 문제를 해결하려면, 서버가 브라우저에게 이렇게 말해줘야 합니다.

“이 origin은 내가 신뢰하고 허용하는 곳입니다.”

이때 응답 헤더에 다음 값들을 추가합니다.

1. 어떤 origin을 허용할지 명시
   • Access-Control-Allow-Origin: https://example.com
   • 또는 개발 단계에서는 *로 모든 출처 허용
     • 실제 서비스에서는 보안상의 이유로 사용하지 않음
2. 허용할 메서드와 헤더 명시
   • Access-Control-Allow-Methods: GET, POST, PUT, DELETE
   • Access-Control-Allow-Headers: Content-Type, Authorization
3. 크리덴셜(쿠키) 포함 요청 시
   • Access-Control-Allow-Credentials: true
   • 이 경우 Allow-Origin은 *를 쓸 수 없고 정확한 도메인을 지정해야 합니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
            .allowedOrigins("http://localhost:3000")
            .allowedMethods("GET", "POST", "PUT", "DELETE")
            .allowedHeaders("*")
            .allowCredentials(true);
    }
}