5장 HTTP/1.1의 시멘틱스: 확장되는 HTTP의 용도
HTTP/1.1 이후에 확장된 프로토콜과 새로운 규약을 사용한 사례를 소개
•
파일 다운로드(파일명 지정)
•
다운로드 중단과 재개(범위 액세스)
•
XMLHttpRequest
•
GeoLocation
•
X-Powered-By
•
Remote Procedure call
•
WebDAV
•
웹사이트 간 공통 인증 및 허가 플랫폼
5.1 파일 다운로드 후 로컬에 저장하기
브라우저가 파일을 어떻게 처리할진 서버에서 보낸 MIME 타입에따라 결정됩니다.
예를 들어 서버의 응답에 Content-Disposition 헤더가 있다면, 브라우저는 다운로드 대화상자를 표시하고 파일을 저장합니다.
Content-Disposition: attachment; filename=filename.xlsx
Shell
복사
curl 옵션
•
-J/—remote-header-name
◦
Content-Disposition 헤더에 설정된 이름으로 로컬에 저장
•
-0/—remote-name
◦
URL 자체를 이름으로 저장
다운로드 하는 페이지에서 다운로드해주셔서 감사합니다. 만약 다운로드가 시작되지 않을 때는 이곳을 클릭하세요. 이런 문구를 본 적 있을겁니다. 이때 서버는 두개의 URL을 제공하는데, 하나는 실제로 파일을 다운로드하는 페이지며 Content-Disposition 헤더로 다운로드할 파일을 Body로 반환합니다. 또하나는 HTML 페이지를 반환하는데 거기에 위 메시지와 함께 <meta http-equiv=”refresh” content=”0;URL=./download_file”>라는 URL사이트로 0초만에 refresh 될 것임을 의미하는 태그가 포함되어 있습니다.
5.2 다운로드 중단과 재시작
HTTP는 다운로드가 중단되면 중단 지점부터 다시시작했습니다.(RFC 2616) 최신은 HTTP/1.1에서 추가된 RFC 7233 입니다.
서버가 범위 지정 다운로드를 지원하는 경우 Accept-Ranges 헤더를 응답에 부여하는데 bytes, none 두가지를 가질 수 있습니다. 이때 재다운로드 시 파일 변경을 감지해야하기 때문에 Etag 헤더도 서버에서 받아옵니다. Range 헤더를 추가로 전송해 원하는 범위도 지정해줍니다.
서버가 콘텐츠를 반환할 때 헤더입니다.
HTTP/1.1 206 Partial Content;
...
# 실제로 보낸 바이트 수
Content-Length: 1000
# 실제로 반환한 범위 / 전체 바이트 수
Content-Ranges: 1000-1999/5000
Shell
복사
만약 클라이언트가 지정한 범위가 이상할 경우 다음과 같은 응답이 옵니다.
HTTP/1.1 416 Range Not Satisfiable
...
Content-Ranges: */5000
Shell
복사
5.2.1 복수 범위 다운로드
Ranges 헤더로 범위를 여러개 지정할 수도 있는데 이때 multipart/byterages라는 Content-Type이 옵니다.
# req
Range: bytes=500-999,7000-7999
Content-Type: multipart/byteragnes;
...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: byte 500-999/8000
...처음 지정된 범위 데이터
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: byte 7000-7999/8000
...두 번째로 지정된 범위 데이터
Shell
복사
5.2.1 병렬 다운로드
과거 다운로더들은 통신회선의 불안전, 몰리는 접속시간등의 제한을 극복하기 위해 병렬 다운로드들을 사용했습니다. 현재는 서버에 큰 부담을 주기에 별로 권장되는 사항이 아닙니다. 이들은 CDN등의 기술적 발달로 속도들을 높이고 있습니다.
5.3 XMLHttpRequest
XMLHttpRequest는 클라이언트가 서버에 요청을 보내고, 응답으로 서버가 데이터를 보낼 수 있으며 기본적인 사항에 거의 변함이 없습니다. 하지만 서버측에서 클라이언트로 요청을 보낼 순 없습니다.
var xhr = new XMLHttpRequest();
// 보낼 곳 지정
xhr.open('GET', "/json", true);
xhr.onload = function(){ ... }
xhr.setRequestHeader('X-Custom', 'custom-value');
xhr.send();
JavaScript
복사
$ curl -H "X-Custom=custom-value" /json
Shell
복사
5.3.1 XMLHttpRequest와 브라우저의 HTTP 요청 차이
form과 차이점들이 있습니다.
•
송수신 시 새로고침 X
•
GET, POST 이외 메서드 전송 가능
•
폼의 경우 key:value 만 보낼 수 있고, 응답은 브라우저로 표시되지만 XMLHttpReqeust는 다양한 형식 송수신 가능
•
몇가지 보안상 제약존재
화면을 지우지 않고 웹페이지를 읽어오거나, 시간이나 타이밍에 따라 갱신 가능한 아키텍처를 Ajax(Asynchronous Javascript+XML)라 합니다.
서버에서 blob 형태를 받아오는 것은 다음과 같습니다.
xhr.responseType = 'blob';
xhr.onload = function(e){
if(this.status == 200){
var blob = this.response;
var img = document.createElement('img');
img.onload = function(e){
window.URL.revokeObjectURL(img.src);
};
img.src = window.URL.createObjectURL(blob);
document.body.appendChild(img);
...
}
}
Shell
복사
5.3.2 코멧
코멧이란 XMLHttpRequest에서 양방향 통신하는 기술입니다. 이는 가장 레거시한 구조를 응용한 기술로 폴링과 롱폴링이 있습니다.
폴링
통지를 받는 쪽에서 빈번하게 통지가 없는지 물어보러 가는 방식입니다. 불필요한 요청과 응답이 발생해 자원소비가 심합니다.
롱 폴링
클라이언트가 서버에 요청을 보내면 바로 응답하지 않고 대기하고, 서버가 통신을 종료하거나 타임아웃이 될때까지 응답을 주지않습니다. 이는 서버에서 응답 권한이 있는 점을 응용한 것으로 리버스 Ajax라고 불리기도 했습니ㅏㄷ.
5.3.3 XMLHttpRequest의 보안
XMLHttpReqeust의 보안 제어는 엑세스할 수 있는 정보 제한과 정송 제한 두가지로 구성됩니다.
엑세스 할 수 있는 정보의 제한
•
쿠키
전송 제한
•
도메인
◦
동일-출처 정책(same origin policy): 브라우저가 엑세스하고 있는 호스트에만 접근 가능
◦
브라우저에서 널리 이용되는 엑세스 제한으로 교차 출처 리소스 공유(cross-origin resource sharing)가 있습니다.
•
메서드
◦
CONNECT, TRACE, TRACK을 지정하면 open 메서드를 호출할 때 SecurityError 예외를 호출하게 하기
◦
CONNECT가 가능해지면 악의적인 페이지를 열었을 때 메일 서버로 스팸메일등을 보낼 수 있기 때문
•
헤더
◦
프로토콜 규약이나 환경에 영향을 미치는 것
◦
쿠키처럼 보안에 영향을 주는 것
◦
브라우저의 능력을 넘을 수 없는 것 → 브라우저가 지원하지 않는 압축형식 지정 등 금지
◦
Sec-, Proxy- 금지
◦
쿠키에 엄격한 제한
▪
광고업자등이 사이트 방문이력을 수집해 행동을 파악하는데 이용되는 사이트 외 쿠키 전송(서드파티 쿠키)에 제약
5.4 GeoLocation
5.4.1 클라이언트 자신이 위치를 구하는 방법
GPS가 없는 컴퓨터라면 와이파이등을 이용해 위치정보를 알려줍니다. 와이파이의 경우 고유 ID와 위도 경도를 DB에 사전 구축해둬 이를 통해 조회합니다. 또한 스마트폰은 스스로 위도와 경도를 측정하고 스스로 조회가능합니다.
5.4.2 서버가 클라이언트 위치를 추측하는 방법
지오 IP란 기술이 있는데 지역마다 등록 관리 기관이 있어 기업, 프로바이더 등에 IP 주소를 할당해 정보를 알려줍니다. 지오 IP는 GPS보단 정확성은 떨어지지만, 사용자의 양해를 구하지 않고도 정보를 얻을 수 있어 장점이 있습니다.
5.5 X-Powred-By 헤더
RFC에는 없는 독자적인 헤더지만, 많은 서버에서 시스템 이름을 반환하는데 이용해 사실상 표준이 되었습니다. 이는 보안상 우려가 RFC 1945에도 나와있으며, OS 버전 등 서버이름 이외에 정보는 들어가면 안된다고 나와있습니다. 파이프라이닝의 경우 호환성이 약해 서버를 확인할 필요가 있어 이를 사용했습니다.
이는 극히 일부 상황을 제외한다면 필요없을 것이라고 판단되는 헤더긴합니다.
5.6 원격 프로시저 호출
프로시저는 각 언어가 제공하는 함수, 클래스 메서드 등을 의미합니다. 원격 프로시저 호출이란 다른 컴퓨터에 있는 기능을 자신의 컴퓨터 안에 있는 것처럼 호출하고 필요에 따라 반환값을 받는 구조입니다.
5.6.1 XML-RPC
최초로 규격화된 원격 프로시저입니다. HTTP/1.1이 있을 때 만들어졌지만 사양 예제는 1.0 기준으로 적혀있습니다. Content-Length를 명시해야하므로, HTTP/1.1의 청크방식은 지원하지 않고, 1장, 2장에서 설명한 수준의 단순한 프로토콜 위에 구축되었습니다. 메서드는 POST이며, 인수와 반환값 모두 XML로 표현되어있으며, Content-Type은 항상 text/xml입니다.
5.6.2 SOAP
XML-RPC를 확장해서 만들어진 규격입니다. 서비스 지향 아키텍처안에서 큰 역할을 했습니다. SOAP 자체는 데이터 표현 형식으로 HTTP안에 미니 HTTP와 같은 구조로 되어있습니다. 따라서 HTTP이외에 SMTP를 써서 SOAP 메시지를 주고받을 수 있습니다.
5.6.3 JSON-RPC
SOAP과 반대로 “단순하게”를 방침으로 만들어졌습니다. HTTP이외에 TCP/IP 소켓 등을 사용한 방법도 가정하고 있어 최대공약수적으로 기술되어있습니다.
JSON을 사용해 XML보다 간결하며, 요청할 땐 Content-Type과 Content-Length, Accept를 넣어줘야 하고, 대부분 POST로 전송해야하지만, 멱등(Indepoment)이며넛 안전한 메서드는 GET을 사용할 수 있습니다.
멱등
여러번 시행해도 결과가 같을 때
ex) *1, GET을 통해 같은 데이터 불러오기 등
5.7 WebDAV
HTTP/1.1에는 포함되지 않았지만 수많은 환경에서 지원되고 있습니다. 이는 HTTP를 확장해 분산 파일 시스템으로 사용할 수 있게 한 기술입니다.
WebDAV의 용어입니다.
•
리소스
◦
일반 파일 시스템에선 '파일'이라고 부르지만, WebDAV에선 HTTP 용어를 그대로 이어받아 리소스라 합니다.
•
컬렉션
◦
폴더와 디렉터리에 해당하는 요소입니다.
•
프로퍼티
◦
리소스와 컬렉션이 가질 수 있는 추가 속성으로, 작성 일시, 갱신일시 등입니다.
•
락
◦
분산 파일 시스템은 여러 사람이 동시에 보고 공유할 수 있지만 편집하게될 경우 마지막 전송 이외엔 수정사항이 지워지기 때문에, 먼저 선언한 사람이외에 변경을 거절하는 시스템입니다.
POST, GET, PUT, DELETE 메서드에 COPY, MOVE가 추가되었습니다. POST는 메서드의 리소스만 작성할 수 있으므로, 컬렉션을 작성하는 MKCOL 메서드가 추가되었고, 콜렉션 내의 요소 목록은 프로퍼티로 취득하므로 PROFILND 메서드를 사용합니다. LOCK, UNLOCK 메서드로 파일 잠금 여부를 제어하기도 합니다.
이는 드롭박스, 구글 드라이브 등 많은 곳에서 사용되고 있습니다. GIT또한 HTTPS 방식에서 WebDAV를 사용하고 있습니다.
5.8 웹사이트 간 공통 인증 및 허가 플랫폼
사용자에게 아무런 보조도구가 없다면 중복된 아이디와 비밀번호를 사용하는 사람들이 많아지고, 보안에 취약해지게 됩니다.
인증
로그인하려는 사용자가 누구인지 확인하고, 브라우저를 조작하는 사용자 ID 소유자를 확인합니다.
권한 부여
누구인지 파악 후 권한을 어디까지 부여할 지 결정합니다.
5.8.1 싱글 사인온
기업 내에 사용하는 웹 서비스나 시스템이 많아지면 싱글 사인온이 검토되는데 이는 시스템 간 계정 간리를 따로하지 않고 한번 로그인으로 전 시스템에 유효하게 하는 기술입니다. 이는 정해진 규칙은 아니고, 이런 용도로 사용되는 시스템을 기르키는 명칭입니다.
5.8.2 커베로스 인증
티켓이란 개념을 통해 티켓을 가진 유저만 서버에 접속할 수 있도록 해 안전성을 확보한 통신을 제공하기 위한 프로토콜입니다.
자세한 로직은 스킵…
5.8.3 SAML
SAML(Security Assertion Markup Language)은 웹 계통의 기술(HTTP, SOAP)을 전제로한 싱글 사인온 구조입니다. 원로그인같이 SaaS 형태로 제공되는 서비스도 있습니다. 이는 쿠키로 세션을 관리하는 웹 구조를 따르고, 도메인을 넘어선 서비스간 통합인증을 가능하게 합니다. 이는 마소 365 과같은 것들과 연계할 수 있습니다.
실제 통신에선 사용자가 서비스를 이용하려고 접속했을 때, 서비스 프로바이더는 인증 프로바이더로 Form POST를 사용해 리다이렉트 합니다. 이후 브라우저는 인증 프로바이더 화면을 표시하고, 로그인을 성공하면 인증 프로바이더는 로그인 정보를 서비스 프로바이더로 POST 한 후 사용자가 요청한 페이지의 콘텐츠를 보여줍니다.
5.8.4 오픈아이디
중앙 집중형 ID를 관리하지 않고, 이미 등록된 웹 서비스의 사용자 정보로 다른 서비스에 로그인하는 시스템입니다. 이는 오픈아이티 커텍트로 옮겨가는 추세라 사용가능한 서비스가 많이 줄어든 상태입니다.
5.8.5 오픈 소셜
페이스북에 맞서고자 구글과 마이페이스가 손잡고 개발한 API로 시작했습니다. 오픈 소셜의 경우 오픈아이디 프로바이더에 해당하는 부분이 소셜 네트워크 서비스 제공자입니다. 인증과 권한 부여를 모두 이쪽에서합니다.
5.8.6 OAuth
인증이 아닌 권한을 부여하는 시스템으로 개발되었고, 현재도 활발하게 이용되는 중입니다.
권한 부여 서버
오픈아이디 프로바이더, 사용자는 이 권한 부여 서버의 계정이 있습니다.
리소스 서버
사용자가 허가한 권한으로 자유롭게 엑세스할 수 있는 대상입니다.
클라이언트
오픈아이디와 달리 권한 부여 서버에 애플리케이션 정보를 등록하고 전용 ID(크레덴셜)을 가져와야합니다.
오픈아이디와 OAuth 둘다 화면을 전환합니다만 인증과 달리 권한 부여에서 큰영향을 미칩니다. 오픈아이디는 사용자가 회사에 이 회원이 맞는지 묻는 정도라면, OAuth 2.0은 신용카드 번호를 맡긴 정도라 생각하면됩니다.
5.8.7 오픈아이디 커넥트
오픈아이디 커텍트는 OAuth 2.0을 기반으로 한 권한 부여뿐만 아니라 인증으로 사용해도 문제가 없게 확장한 규격입니다. OAuth 2.0과 차이는 사용자 프로필에 액세스하는 방법을 규격화 했다는 점 정도입니다.