Search
🔵

bc9.3_1.1. title: HTTP 통신 관점에서 주고받게 되는 것은 그냥 문자열 덩어리이다. 실제로 이 문자열 덩어리가 전송 과정에서 어떻게 암호화되고 분해되고 조립되는지는 관심사 밖이다. HTTP는 헤더에 문자열을 어떻게 파싱해서 쓰면 좋을지에 대한 팁을 포함한다.

생성
prev summary
🚀 prev note
♻️ prev note
bc9.3_1. title: OSI 7계층 구조를 단순화한 TCP IP 모델은 TCP 또는 UDP 시스템 위에서 HTTP가 작동함을 시사한다. 예를 들어 브라우저는 자신이 받은 데이터가 TCP를 통해 받은 것인지 UDP를 통해 받은 것인지 신경쓰지 않아도 된다.
bb7.1.1.4. title: HTTP가 주로 사용하는 TCP의 오버헤드를 최소화하기 위해 연결이 지속가능하게 하거나(HTTP1.1) UDP를 기반으로 새로운 프로토콜을 정의하여 HTTP의 기본 전제인 신뢰성(reliablity)을 확보하려는 시도도 있다(HTTP3.0).
next summary
🚀 next note
관련 임시노트
9 more properties
HTTP는 “텍스트 프로토콜”이다. 즉, HTTP 통신 관점에서 주고받게 되는 것은 그냥 문자열 덩어리이다. 실제로 이 문자열 덩어리가 어떻게 암호화되고 분해되고 조립되는지는 관심사 밖이다. 심지어 바이너리 파일(이미지, 동영상)도 Base64 인코딩 등으로 문자열화해서 전송한다.
전송 예시
GET /api/users HTTP/1.1 Host: example.com Content-Type: application/json {"name": "홍길동", "age": 30}
Plain Text
복사
GET /api/users HTTP/1.1같은 것들도 문자열 안에 담기로 약속한 규약이다. 실제로 TCP 시스템 콜만을 이용해서 C언어로 HTTP 프로토콜을 구현하면 다음 스트링을 한땀한땀 박아넣어야 한다.
[메서드] [경로] [HTTP버전]\r\n [헤더이름]: [헤더값]\r\n [헤더이름]: [헤더값]\r\n \r\n [바디 내용]
Plain Text
복사
응답 예시
HTTP/1.1 200 OK Content-Type: application/json Content-Length: 45 {"id": 123, "name": "홍길동", "status": "created"}
Plain Text
복사
객체가 아니라 문자열 덩어리를 주고받기 때문에, 이 문자열을 어떻게 파싱해서 쓰면 좋을지에 대한 정보를 헤더에 담는 것이다.
POST /api/users HTTP/1.1 Content-Type: application/json {"name": "홍길동", "age": 30}
Plain Text
복사
HTML 파일의 경우,
GET /index.html HTTP/1.1 HTTP/1.1 200 OK Content-Type: text/html <html> <head><title>제목</title></head> <body>안녕하세요</body> </html>
Plain Text
복사
CSS 파일의 경우,
GET /style.css HTTP/1.1 HTTP/1.1 200 OK Content-Type: text/css body { background-color: blue; font-size: 16px; }
Plain Text
복사
이미지 파일의 경우,
GET /photo.jpg HTTP/1.1 HTTP/1.1 200 OK Content-Type: image/jpeg [바이너리 데이터가 문자열로 인코딩된 형태]
Plain Text
복사
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
1.
앞의 글은 ‘신경쓰지 않아도 된다’라고 이야기하지만 신경쓰지 않기 때문에 HTTP가 어떤 추상화 수준의 정보를 주고받는지에 대한 이야기를 다루지 않는다.
2.
앞의 글은 HTTP가 신뢰성을 요구한다는 이야기를 한다. 우리가 HTTP를 ‘문자열’이라고 편하게 생각할 수 있는 이유는 “GET /api/users HTTP/1.1” 라는 문자열을 보낼 때, 수신 측에서 “G /api/users HTTP/1.1” 같이 일부가 누락된 채로 받거나, “{user: 1, money: 1000}”과 같은 정보가 “money: 1 {user: 1000}” 처럼 순서가 뒤섞이거나 하는 일이 없기 때문이다. 이를 신뢰성이라고 한다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
1.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
1.
None
ref : 생각에 참고한 자료입니다.
1.
None