1. 프로토콜(Protocol)
- 네트워크에서 데이터를 주고받을 때 양쪽이 같은 방식으로 이해할 수 있도록 미리 정의한 규칙
- 만약 규칙이 없다면 데이터를 받더라도 그 의미를 해석할 수 없음
- 실생활 비유: 편지 봉투에 주소, 우표, 발신자 위치가 정해져 있어야 우체부가 전달 가능
→ 이런 형식적 규칙이 곧 프로토콜
2. HTTP (HyperText Transfer Protocol)
-
웹에서 가장 기본이 되는 통신 규칙
-
하이퍼텍스트(HTML)를 전송하기 위한 프로토콜
-
특징
-
텍스트 기반 : 사람이 읽을 수 있는 문자열 형식 (Binary가 아닌 Text로 메시지를 구성)
-
Stateless (무상태성) : 요청이 끝나면 서버는 클라이언트 정보를 기억하지 않음
-
같은 클라이언트라도 두 번째 요청을 보낼 때 "누군지" 모름
→ 그래서 쿠키/세션 같은 기술이 필요 -
Connectionless (비연결성) : 요청/응답이 끝나면 서버-클라이언트 연결을 끊음
-
확장성 : HTTP 헤더를 통해 새로운 기능을 쉽게 추가 가능 (예: 인증 토큰, 캐시 제어, CORS 설정 등)
-
3. HTTP 메시지 구조
- HTTP 통신은 결국 메시지를 주고받는 것
- 편지 비유
- Header (머리말): 편지 겉봉투(누가, 언제, 어떤 형식으로 보낸 편지인지 설명)
- Body (본문): 실제 내용물 (HTML, JSON, 이미지 등)
- 응답 상태 코드
- 응답 메시지에는 상태 코드(Status Code) 포함 → 요청이 어떻게 처리되었는지 표시
- 자주 쓰이는 범주
200 OK : 성공
302 Found : 리다이렉트
400 Bad Request : 클라이언트 요청 오류
404 Not Found : 요청한 리소스 없음
500 Internal Server Error : 서버 내부 문제
- 정리 : 4xx는 내 잘못(클라이언트 문제), 5xx는 서버 잘못
4. HTTP 요청 메서드
- GET
- 목적 : 리소스 "조회"
- 데이터는 URL 뒤에 붙는 쿼리스트링으로 전달 → 소량 데이터 적합
- 단점 : 데이터가 URL에 노출되어 보안 취약
- 장점 : 북마크/공유 가능
- POST
- 목적 : 리소스 "생성/제출"
- 데이터는 요청 메시지 Body에 담음 → 대용량 데이터 가능
- URL에 노출되지 않음 → 보안상 유리하지만 암호화(TLS)가 없다면 여전히 노출될 수 있음
- 따라서 진짜 보안을 원한다면 HTTPS(HTTP + TLS) 필수
| 메서드 | 설명 | 주요 특징 / 사용 예시 |
|---|---|---|
| HEAD | 리소스의 헤더만 요청 | - GET과 같지만 Body는 없음 - 리소스의 존재 여부/메타데이터 확인 시 사용 (예: 파일 크기, 최종 수정일) |
| GET | 리소스 조회(Read) | - 가장 많이 사용되는 메서드 - 데이터는 URL(Query String)로 전달 - 요청 Body 없음 |
| POST | 리소스 생성(Create), 서버에 데이터 전송 | - 회원가입, 글쓰기, 파일 업로드 등 - 데이터는 Body에 담아 전송 - 대용량/민감 데이터 처리 적합 |
| PUT | 리소스 전체 수정/업로드 | - 해당 URL에 요청한 데이터로 리소스를 통째로 교체 - 없으면 새로 생성 - 예: PUT /users/1 → id=1 사용자 정보 전체 업데이트 |
| DELETE | 리소스 삭제 | - 요청한 리소스 제거 - 예: DELETE /users/1 |
| PATCH | 리소스 부분 수정 | - PUT과 달리 일부 속성만 수정 - 예: PATCH /users/1 { "email": "new@x.com" } |
| TRACE | 요청이 서버까지 가는 경로 추적/디버깅 | - 루프백(Loopback) 테스트 - 실제로는 거의 사용 X (보안상 차단하는 경우 많음) |
| OPTIONS | 서버가 지원하는 메서드 목록 조회 | - 예: CORS 사전 요청(Preflight Request) - 특정 URL에서 사용 가능한 메서드 확인 가능 |
5. 텍스트 vs 바이너리 파일
- 텍스트 파일
- 문자만 저장 (예: txt, html, xml, json 등)
- 숫자도 문자 코드(예: 아스키, 유니코드)로 변환하여 저장
- 바이너리 파일
- 데이터가 숫자 그대로 저장됨 (예: 이미지, 영상, 실행파일 등)
- 구분 방법 : 메모장에서 열었을 때 읽을 수 있으면 텍스트, 깨지면 바이너리
- I/O 동작 차이
- 텍스트 I/O : 숫자 → 문자로 변환 (가독성 위주)
- 바이너리 I/O : 숫자 → 숫자 그대로 (정확성/효율성 위주)
6. MIME (Multipurpose Internet Mail Extensions)
- HTTP는 원래 텍스트 기반이므로, 이미지/동영상 같은 바이너리 데이터를 전송하기 위해 데이터의 종류를 알려주는 형식(MIME 타입) 필요
- 예시
- text/html : HTML 문서
- image/png : PNG 이미지
- application/json : JSON 데이터
- application/pdf : PDF 문서
- 브라우저나 서버는 이 MIME 타입을 보고 데이터를 어떻게 처리할지 결정
- (예: image/jpeg라면 브라우저가 이미지 뷰어를 사용해서 보여줌)
7. Base64
- 바이너리 데이터를 텍스트 문자(AZ, az, 0~9, +, /)로 변환하는 인코딩 방식
- 이유 : HTTP가 텍스트 기반이라, 바이너리를 안전하게 전송하려고 사용
- 단점 : 크기가 약 33% 커짐
- 사용 예 :이메일 첨부파일 전송 / JSON 안에 이미지/파일 삽입할 때 (data:image/png;base64,...) / JWT 토큰 인코딩
