브라우저는 서버와 “대화”하고 있다

처음 개발을 공부할때는 페이지 이동을 그냥 화면 전환처럼 생각했었던것 같다.

페이지 이동도 맞지만

브라우저
↔ 서버

간의 요청/응답 흐름을 더 눈여겨 보아야하는것 같다.

브라우저가 URL을 입력받으면

Request 전송
→ 서버 처리
→ Response 반환
→ 브라우저 렌더링

이 반복된다.

Request

처음엔 그냥 "서버에 데이터 보내기" 라고만 생각했다.

근데 실제 Request 안에는 생각보다 많은 의미가 들어 있다.

Method는 “의도”를 표현한다

예전엔 GET/POST 차이 정도를 단순 암기로 외웠다.

근데 실제로는 이 요청이 무엇을 하려는가 를 나타내는 의미 자체였다.

GET

GET /users

조회 목적. 보통 Body를 사용하지 않는다.

POST

POST /users

생성 목적.

Body에 데이터를 담는다.

PUT vs PATCH

PUT:

전체 수정

PATCH:

일부 수정

의미에 가깝다.

Header에 담긴 정보

Header는 HTTP의 메타데이터 공간이다.

예를 들어

Content-Type: application/json

이건

"Body 데이터 형식이 JSON입니다"

라는 의미다.

Authorization: Bearer token

이건 인증 정보.

Cookie: sessionId=abc123

이건 브라우저 인증 상태.

Cache-Control: max-age=3600

이건 캐시 정책.

즉 Header 하나로

인증
캐시
쿠키
CORS
보안 정책

전부 제어된다.

Body는 “실제 데이터”

여긴 상대적으로 직관적이다.

보통

{
  "name": "kim"
}

같은 JSON을 담는다.

근데 여기서도 중요한 건

Content-Type

와 연결된다는 점이었다.

예를 들어

Content-Type: application/json

이면 서버는 JSON으로 파싱한다.

multipart/form-data

면 파일 업로드처럼 처리한다.

즉 Header와 Body는 연결되어 움직인다.

Response

Status Code는 브라우저와의 약속

401

인증 필요

보통 로그인 만료 처리.

403

인증은 됐지만 권한 없음

404

리소스 없음

500

서버 내부 오류

HTTPS를 공부하면서 생각이 완전히 바뀌었다

예전엔 HTTPS를 그냥 브라우저 자물쇠 아이콘정도로 생각했다.

근데 실제론 웹 보안의 기본이다.

HTTP는 생각보다 위험하다

처음에 개인프로젝트를 AWS에 올리고 SSL/TLS 인증서를 적용해서 HTTPS를 활성화된다고 알았을때는

그냥 요청 보내고 응답 받는 거 아닌가? 활성화 꼭 해야하나 싶었다. 근데 꼭 필요하다!

근데 HTTP는 기본적으로 평문이다.

즉 중간에서 패킷을 보면

비밀번호
쿠키
요청 데이터

가 그대로 보일 수 있다.

http에서는 패킷스니핑이 쉽게 일어날수있다.

HTTPS의 핵심은 “암호화 + 신뢰”

HTTPS는 단순 암호화만이 아니다.

핵심은

데이터 도청 방지
데이터 변조 방지
서버 신뢰성 검증

전부 포함한다.

HTTPS가 없으면 Cookie 보안도 의미가 줄어든다

예를 들어

Set-Cookie: token=abc; Secure

이 옵션.

HTTPS가 없으면 쿠키 자체가 네트워크에서 노출될 수 있다.

즉

HttpOnly
SameSite
JWT

전부 결국 HTTPS 위에서 의미가 커진다.

NETWORK