SSP-DSP 간에 HTTP로 통신한다길래 이 김에 한번 정리. https://simplenotion.tistory.com/18?category=1001961 의 광고 특화/심화버전이라고 보면 된다.
HTTP(s)
HTTP는 HyperText Transfer Protocol로서, HTML 문서를 포함한 다양한 형식의 데이터를 웹에서 주고받는 데 사용된다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 모델에 기반한다. 즉, 웹 브라우저(클라이언트)가 웹 서버에 요청을 보내고, 웹 서버는 응답을 보내는 방식으로 동작한다. 여러 종류의 데이터가 전송될 수 있고(text/html, application/json, application/xml, audio/mpeg 등 header에 데이터 타입을 명시한다) 여러 가지 상태코드 (404 not found 등) 를 기반으로 성공 여부와 오류 상황을 나타낸다. 왜, 500번대는 니(서버)잘못. 400번대는 내(클라)잘못. 그런거. 200은 쏘굳~
HTTP와 Bidding
Bid Request - Response 간에는,
- HTTP 1.1 또는 2.0 기반으로 서버 대 서버(Server-to-Server) 통신한다.
- REST API 방식이 아니라, OpenRTB(Open Real-Time Bidding) 표준을 따르는 특수 목적 HTTP 통신: post만 사용하고, 응답이 항상 200번대고, 이런저런 이유 때문에 restful하지는 않다고 한다.
HTTP 1.1? 이라고 해서 맞는 정보인지 의심했는데, Wikipedia에 따르면 HTTP 1.1, 2.0, 3.0이 각각 1/3씩 나눠먹고 있다고 (물론 전체 요청 수에서는 차이가 벌어진다).
- 특히 openRTB서는 HTTP/2는 헤더 압축(HPACK)과 세션 관리 오버헤드가 있어 미세 지연이 발생할 수 있다는 점,
- HTTP/2의 가장 큰 장점은 "멀티플렉싱(한 커넥션 안에 다중 요청)"인데, RTB에서는 요청과 응답이 1:1 매칭이 기본이라는 것
이 여전히 주요 SSP(Magnite, Xandr, PubMatic 등)와 주요 DSP(The Trade Desk, MediaMath 등) 가 1.1에 의존하고 있다는 이유이겠다.
HTTP Get vs Post
| GET | POST | |
| 데이터 전달 위치 | URL에 쿼리 스트링으로 전달 (?key=value) | HTTP Body에 담아 전달 |
| Body? | 통신 규약 상 지원 않음 (비표준적으로 받아주는 경우 있으나 기본적으로 Body 기대 x) | |
| 용량 제한 | 브라우저/서버에 따라 URL 길이 제한 존재 (2KB-8KB) | 사실상 무제한 |
| 보안성 | 낮음, URL 직접 노출 | Body에 담겨 상대적으로 노출 적음 |
| 주요 용례 | 조회, 검색 | 생성, 변경 |
| 멱등성 | 여러 번 호출해도 결과 같음 | 매 호출마다 결과가 달라질 수 있음 |
왜 RTB서는 Post인가
- 일단 OpenRTB 스펙 자체가 POST/JSON 전송을 명시하고 있다.
- BiRequest는 수십~수백 개의 필드를 포함하는 복잡한 JSON이다 (GET 쿼리스트링으로는 용량 초과 위험이 크다). JSON처럼 복잡하고 크기가 큰 구조화 데이터는 Body에 담는 POST 방식에 의존한다.
Bid Request 예시를 보자
POST /openrtb2/bid HTTP/1.1
Host: dsp.example.com
Content-Type: application/json
Content-Length: 450
Connection: keep-alive
{
"id": "req-abc123",
"imp": [{
"id": "1",
"banner": {
"w": 300,
"h": 250
},
"bidfloor": 0.5
}],
"site": {
"id": "site-001",
"name": "Example Site",
"domain": "example.com"
},
"device": {
"ua": "Mozilla/5.0",
"ip": "192.0.2.1"
},
"user": {
"id": "user-xyz"
},
"cur": ["USD"]
}| Header | POST /openrtb2/bid HTTP/1.1 | HTTP 메소드: POST. URL 경로: /openrtb2/bid. HTTP 버전: 1.1. |
| Host: dsp.example.com | 요청 대상 서버 | |
| Content-Type: application/json | 보낼 데이터 형식은 JSON임을 명시 | |
| Content-Length: 450 | 바디(body) 길이(바이트 수) | |
| Connection: keep-alive | 연결 유지 요청 | |
| Body | id(bid request 식별자), imp(인벤토리 정보 배열), site/app, device 등... | 실제 입찰 요청 데이터 (구조화된 JSON) |
그러면 Bid Response는?
| Bid Request | SSP ➔ DSP로 보내는 HTTP POST 요청 (Body에 JSON 담음) |
| Bid Response |
DSP ➔ SSP로 보내는 HTTP 응답(HTTP Response) (Response Body에 JSON 담음) |
Bid Response는 DSP가 "HTTP Response Body"에 JSON을 담아서 SSP에 반환하는 것이지 별도로 "DSP가 POST 요청을 새로 보내는 것"이 아니다.
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 320
Connection: keep-alive
{
"id": "req-abc123",
"seatbid": [{
"bid": [{
"id": "bid-xyz456",
"impid": "1",
"price": 1.75,
"adm": "<html>광고소재 HTML 또는 VAST XML</html>",
"crid": "creative-001",
"w": 300,
"h": 250
}]
}],
"cur": "USD"
}
즉
- Bid Request = HTTP POST + JSON Body 전송
- Bid Response = HTTP 200 OK + JSON Body 반환
인 셈이다.
'Web' 카테고리의 다른 글
| HTTP Request 와 Request Methods (4) | 2022.05.29 |
|---|---|
| Cookie 쿠키 와 3rd party cookie (1) | 2022.02.26 |
| Proxy와 Redirect (2) | 2022.02.19 |
