해당 게시물은 아래의 HTTP 완벽 가이드를 공부하면서 정리하는 게시물입니다.
정리는 목록 순으로 진행 할 예정이며 추가 정보, 의견 언제나 감사합니다.
1차 - 22.05.03 시작
1장 HTTP : 웹의 기초
1장에서는 HTTP가 트래픽을 어떻게 전송하는 가를 자세히 다룬다.
미디어 타입 : HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME(Multipurpose Internet Mail Extensions) 타입이라는 데이터 포맷 라벨을 붙인다.
ex) Content-type : image/jpeg
Content-length : 12984
1번의 image = MIME
URI : uniform resource identifier - 통합 자원 지시자
ex) https:// www.asg.com /into/hello.html
https:// - 스킴, 리소스에 접근하기 위해 사용 되는 프로토콜 서술
www.—-.com - 서버의 인터넷 주소
/into/hello.html - 리소스
TCP(Transmission Control Protocol) 커넥션 - 전송 제어 프로토콜
HTTP는 계층형 프로토콜이며 네트워크 통신의 핵심적인 세부사항에 대해서 신경 쓰지 않는다.
대신 대중적이며 신뢰성이 있는 인터넷 전송 프로토콜 TCP/IP에게 해당 업무는 맡긴다.
기본적인 스펙은
- 오류 없는 데이터 전송
- 순서에 맞는 전달(언제나 보낸 순서대로 도착한다.)
- 조각나지 않는 데이터 스트림 (언제든 어떤 크기로든 보낼 수 있다.)
TCP/IP는 TCP와 IP가 층을 이루는, 패킷 교한 네트워크 프로토콜의 집합이다.
네트워크의 개념상 HTTP프로토콜은 TCP 위의 계층이다.
우선 HTTP 클라이언트가 서버에 메세지를 전송 할 수 있게 되기 전에, 인터넷 프로토콜IP 주소와 포트번호를 사용하여 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.
웹 구성 요소
- 프락시 - 중계자, 서버와 클라이언트 사이에 위치
- 캐시 - 하드 저장 정보, 자주 찾는것에 대한 사본을 저장한다.
- 게이트웨이 - 다른 애플리케이션과 연결된 특별한 서버 , 아예 다른 서버의 중계자 주로HTTP트래픽을 다른 프로토콜로 변환
- 터널 - 단순히 HTTP통신을 전달하기만 하는 특별한 프락시, 두 커텍션 아이에 raw인 상태의 데이터를 열어보지 않고 그대로 전달 ex)사내 방화벽을 통한 데이터 전달
- 에이젠트 - 자동화된 HTTP요청을 만드는 준지능적(semi-intelligent) 웹 클라
HTTP : 기본 포트 80
HTTPS : 443
FTP : file transfer protocol
클라 to 서버 - (인바운드)
서버 to 클라 - (아웃바운드)
엔터티 본문 - 데이터 블록
상태코드 - 따로 정리 예정
커넥션 관리
HTTP, HTTPS의 차이는 중간에 TLS or SSL 보안 계층이 존재 하느냐 마냐다
TCP 커넥션 유지하기 - 네 가지 값으로 식별
<발신자 IP주소, 발신자 포트, 수신자 IP 주소, 수신자 포트>
HTTP는 TCP 바로 위에 있는 계층이므로 해당 트랜잭션은 TCP 성능의 영향을 받는다.
HTTP 커넥션 관리
우선 HTTP 는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버와 같은 중개 서버가 놓이는 것을 허락한다.
HTTP는 순서대로 거치기 때문에 현재 맺고 있는 커넥션에만 적용 될 옵션을 지정해야할 때가 있다.
다음 살펴볼 HTTP Connection 헤더 필드는 커넥션을 쉼표로 구분하고 있으며, 그 값들은 다른 커넥션에 전달 되지 않는다. 이번 커넥션 이후 연결을 끊을 필요가 있다며 Connection:close 하면 된다.
→ Conntection Head : 전달 하는 토큰 세가지
HTTP 헤어 필드 명은, 이 커넥션에만 해당 되는 헤더들을 나열
임시적인 토큰 값, 커넥션에 대한 비표준 옵션을 의미
close값, 커넥션 작업이 완료되면 종료 되어야 함을 뜻함
Connectoin 헤더에 있는 헤더 필드는 메세지를 다른 곳으로 전달하는 시점에서 삭제 되어야한다.
헤더에는 홉별(hop-by-hop)이라는 헤더 명을 기술하는데 이것을 헤더 보호기라고 한다. - Connection헤더에 명시된 헤더들이 전달 되는것을 방지하기 때문이다
HTTP 애플리케이션이 Connection 헤더와 함께 메세지를 전달반으면, 수신자는 송신자에게서 온 요청에 기술되러 있는 모든 옵션을 적용한다. 그 후 홉(hop)에 메세지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술 되어 있던 모든 헤더를 삭제한다.
순차적인 트랜잭션처리에 의한 지연
병렬 - 여러개 TCP 커넥션을 통한 동시 요청
→ 단점 : 각 트랜잭션마다 새로운 커넥션을 맺고 끊기에 시간과 대역폭이 소요 된다.
: 새로운 커넥션은 TCP의 느린 시작 때문에 성능이 떨어진다.
: 실제로 연결 가능한 병렬 커넥션의 수에는 제한이 존재한다.
→ 병렬 커넥션을 사용하긴 하지만 적은 수 (4개)의 병렬 커넥션만을 허용한다. 서버 특정 클라이언트로 부터 과도한 수의 커넥션이 맺어졌을 경우 임의로 끊어버릴 수 있다.
지속 - 지연 제거를 위한 TCP 커넥션 재활용, 사이즈 지역성, 서버 or 클라가 커넥션을 끊기 전까지는 유지
Keep-Alive (HTTP 1.0/ HTTP 1.1)
Keep-Alive + Dumb 프락시 (HTTP1.0)
Dumb 프락시 : 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로 다음 프락시에 전달한다.
해당 방법은 프락시가 1개일때만 적용 가능하다.
HTTP(1.1)
지속 커넥션 - 기본, 닫기 위해서는 Connection:close 필수
파이프라인 - 공유 TCP 커넥션을 통한 HTTP 요청
HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝을 할 수 있다.
제약 사항
→ 커넥션이 지속 커넥션임을 확인하기 전까지는 파이프라인을 이어서는 안된다.
→ 요청과 응답은 같은 순서로 와야한다.
→ 커넥션이 언제 끊어지더라도 언제들 다시 요청을 보낼 준비가 되어 있어야 한다. 멱등성
→ POST 요청 같이 반복해서 보낼 시 문제가 될 수 있는 요청은 파이프라인을 통해서 보내면 안된다.
다중 - 요청, 응답 중재 ( 아직 )
2장
웹 서버의 역할
- 요청, 응답, 리소스 접근, 트랜잭션 로그
요청의 각 메세지 헤더는 CRLF로 끝난다.
단일 스레드, 멀티 프로세스, 멀티 스레드, 다중 I/O서버, 다중 멀티스레드
프락시
개인, 공용 - 필터, 제어자, 방화벽, 웹 캐시, 대리인, 콘텐츠 라우터, 트랜스코더, 익명화
WHERE TO PUT
출구 - 트래픽 제어
입구 - 다운속도 제어, 사본 저장
대리 - 제일 마지막 서버 앞에, 보안 기능
네트워크 교환 프락시 - 트래픽 감시, 인터넷 페어링 교환 시점
프락시 - 원 서버에서
가깝다 : 인바운드
멀다 : 아웃 바운드 (클라에게 가깝다)
프락시 URI VS 서버 URI
클라 -> 서버 : 스킴(ex : http ftp https..), 호스트, 포트번호, 부분 URI
클라 -> 프락시 : 완전한 URI
Via헤더
발송자들의 프로토콜을 다루는 능력을 확인하기 위해서 사용
via헤더 필드 - 중간 노드 (프락시, 게이트웨이)의 정보를 나열
메세지 or 중간 노드를 지날 때 via 목록 끝에 추가
ex : viz/1.1 porxy ~~/1.0 cache ~~ -> '/'로 구분
4가지 정보
- protocol(1.0/1.1), 이름(호스트/포트 번호- 없다면 기본 포트로 간주), 버전(필수), 노드 이름(필수), 코멘트
프락시는 네트워크의 루프를 탐지하기 위해 via 헤더를 사용, 프락시는 요청전에 자신을 가르키는 유일한 문자열을 via 헤더에 삽입해야함.
캐시 (속도 개선을 위해 주로 사용 됨)
- 적중, 부적중
- 재검사 (validation) - 304 not modified since/ 404 not found
- HTTP 는 클라이언트에게 적중 부적중, from 원서버인지 알려주지 않는다 (알기 위해 viz헤더 필요)
WHEN 사용?
- 요청 받기, 파싱, 검색, 신선도 검사, 응답 생성, 전송, 로깅, 사본 신선 유지, 재검사, 약한 검사(작은 변화 허용), 강한 검사(strict),
캐시 제어(cache-control:no-store, no-cache -> 캐시가 검증 X , 객체 응답을 막는다 /
must-revalidate -> 캐시가 이 객체의 신선하지 않은 사본을 원 서버와 최초의 재검사 없이는 제공 돼서는 안됨을 의미 /
Expires, max-age -> 신선도), 강제 신선도 제약, 아파치 HTTP헤더 제어(mod-headers : 개별 헤더 설정/ mod-cen-meta : expires헤더 자동 생성)
게이트웨이, 터널 , 릴레이
게이트웨이 - 서로 다른 애플리케이션간의 HTTP 프로토콜을 가능하게 해줌 (HTTPS 전용 443 포트와 같이 잘 알려진 곳으로 다녀야한다.)
터널 - HTTP 커넥션으로 트래픽 전송하는데 사용, HTTP프로토콜을 지원하지 않는 앱한테 접근하는 방법 제공
릴레이 - HTTP 프락시로 한번에 한 개의 홉에 데이터를 전달 사용, HTTP 명세를 완전히 준수하지 않는 간단한HTTP 프락시
2장 5월 20일 업로드
3장 - 식별, 인가, 보안
클라이언트 식별과 쿠키
Referer 헤더 - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL을 가르킨다.
유닉스 시스템에서 getpeername 함수를 호출하면 클라이언트의 IP 주소를 받을 수 있다.
사용자 로그인 - 명시적 식별 요청
뚱뚱한 URL
사용자의 상태 정보를 포함하고 있는 URL
각 URL은 사용자에게 할당한 식별번호를 붙여서 추적한다.
유일한 ID가 생성
쿠키
쿠키와 캐시는 충돌이 있을 수 있고, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.
쿠키의 타입
세션 쿠키 -> 사용자가 브라우저를 닫으면 삭제 된다.
둘의 차이점은 삭제 되는 시기
보통 사이트에 두개 혹은 세개의 쿠키를 보낸다.
이유: 모두 보낼 시 성능 저하, 특정한 서버의 특정한 이름/값 쌍으로 포함 타 사이트에는 무의미한 값, 잠재적인 개인정보 문제를 일으킨다.
-> 보통 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달
ex) user = mary17 쿠키를 .~.com 도메인을 가지고 있는 모든 사이트에 전달 한다.
ex) set-cookie: user="mary17"; domain=".~.com"
set-cookie 헤더는 쿠키의 이름과 값을 가져야 한다.
이름 = 값 : 필수 속성 - 이름과 값 모두 따음표로 감싸지 않은 세미콜론, 등호, 공백을 포함하지 않는 문자열이다.
Expires : 선택 속성 - 생명 주기
Domain : 선택 속성 = 서버 호스트 명으로만 쿠키를 전송한다.
Path : 선택적인 속성
Secure : 선택적인 속성 : HTTP가 SSL 보안 연결을 사용 할때만 쿠키를 전송한다.
쿠키 : [필수] 이름=값, version/ [선택] comment, commentURL, discard, domain, max-age, path, port, secure
쿠키와 캐싱
쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의 필요
인증
다이제스트 인증!
기본 인증 : 사용자에게 id 와 pw를 입력 할 수 있는 대화 상자를 연다.
프락시 인증 : 프락시 서버에서 접근 정책을 중앙 관리가 가능하여 회사 리소스 전체에 대해 통합적인 접근 제어를 하기 위하여 프락시 서버를 사용하면 좋다.
다이제스트 인증
핵심 : 공개된 정보, 비밀 정보, 시한부 난스값들의 단방향 요약
다이제스트 인증은 기본 인증과 호환되는 더 안전한 대체제로 개발 되었다.
기본 HTTP 인증과 다른 점 :
- 비밀번호를 절대로 네트워크를 통해 평문으로 전달하지 않는다. -> 지문, 요약(a)해서 보낸다, 요약 - 암호 체크섬(cyptographic checksums)
- 인증 체결을 가로채서 재현하려는 사람을 차단한다.
- 구현하기에 따라서, 메세지 내용 위조를 막는 것도 가능하다.
- 잘 알려진 형태의 공격을 막는다.
요약은 비밀번호 그 자체이다. 그러므로 요약을 가로채서 공격하는 것을 대비하여 난스(nonce )를 사용한다.
HTTP
서버 인증, 클라이언트 인증, 무결성, 아호화, 효율, 편재성, 관리상 확정성, 적응성, 사회적 생존성
암호화 전 원본 : 평문
어떤 키를 사용 했는지 비밀
디지털 서명
서명은 암호 체크섬, 위조 방지,
디지털 인증서 (certs)
인증서의 내부 - 대상 이름, 유효 기간, 인증서 발급자, 발급자의 디지털 서명
서버인증 인증서
-> 웹 사이트 (이름, 호스트명 , 공개키), 서명 기관 (이름, 서명)
SSL 핸드셰이크
프로토콜 번호 교환, 암호 선택, 신원 인증, 세션 키 생성
4장 - 엔터티, 인코딩, 국제화
국제문자 이스케이핑 - US-ASCII 범위(0-127)안에서만
고려사항
헤더는 반드시 US-ASCII문자집합의 글자들로만 이뤄짐, 벗어난 글자는 라이브러리가 지원하지 않음
날짜 - 규정은 있지만 모든 사이트가 해당 규정을 따르는것은 아니다. 최대한 수용해야함.
도메인 - 퓨니코드를 이용해서 이를 지원, 다국어 사이트는 이름을 변환함
협상과 트랜스코딩
서버 내의 페이지 중에서 클라이언트와 맞는 페이지 판단법
-> 클라이언트 주도 - 클라에게 선택지를 전해 줌, 두단계의 요청, 응답으로 속도가 느리다.
-> 서버 주도 - 요청 헤더 검증 - 클라주도 협상 보다 좀 빠름
-> 투명 - 클라 주도보다 빠르며, 정형화된 명세가 없다.
아파치 내용 협상
- 콘텐츠 제공자가 각각의 버전에 해당하는 파일들을 아파치 서버의 디렉토리에 넣어주어야 한다.
-> 디렉토리에서, 베리언트 (variant)를 갖는 각 웹 사이트의 각 URI를 위하여 type-map 파일을 만든다. 각 대응 협상 헤더들 나열
->자동으로 type-map파일 생성 MultiViews지시어
type-map 파일
아파치 설정 파일에 파일 접미사를 명시한 핸들러 추가
5장 - 콘텐츠 발행 및 배포
안정적인 웹 서버 만들기
미러링된 서버 팜
서버팜은 서로 대신 할 수 있고 식별 가능하게 설정된 웹 서버들의 집합이다.
원본 컨텐츠를 가진 서버 : 마스터 원 서버
HTTP 리다이렉션 - 콘텐츠 URL은 마스터 서버 ip, 마스터 서버는 복제 서버로 리다이렉트
DNS 리다이렉션 - 콘텐츠 URL은 4개의 ip, DNS 서버는 클라이언트에게 전송할 ip선택 가능
CDN 대리 캐시, 프락시 캐시
FrontPage 보안
리다이렉션과 부하 균형
리다이렉션 기술은 보통 메세지가 프락시, 캐시, 서버 팜의 특정 웹 서버 중 어디에서 끝나는지 판별하기 위해 사용한다.
WHY?
리다이렉션은 HTTP 애플리케이션 웹에서는 피할 수 없는 현실이다.
-신뢰할 수 있는 HTTP 트랜잭션의 수행
- 지연 최소화
- 네트워크 대역폭 절약
을 원하기 때문
방법 (서버로)
- HTTP 리다이렉션
- DNS 리다이렉션
- 임의 캐스트 어드래싱
- 아이피 맥 포워딩
- IP 주소 포워딩
방법(프락시)
- 명시적인 브라우저 설정
- 프락시 자동 설정
- 웹 프락시 조직 프로토콜
- 인터넷 캐시 프로토콜
- 캐시 배열 라우팅 프로토콜
- 하이퍼텍스트 캐싱 프로토콜
로깅
로그란?
서버나 프락시 문제를 찾거나, 웹 사이트 통계 내릴때
주로
- HTTP 메서드
- 클라이언트와 서버의 HTTP 버전
- 요청받은 리소스의 URL
- 응답 HTTP 상태 코드
- 요청 과 응답 메세지의 크기 (모든 엔티티 본문을 포함)
일반 로그 포맷
- remotehost : 요청한 컴퓨터의 호스트명
- username : 인증된 요청자의 사용자 이름
- auth-username : 인증을 수행했다면, 인증된 요청자의 이름이 있다
- timestamp : 요청 날짜와 시간
- request-line : HTTP 요청의 행
- response-code : HTTP 상태 코드
-response-size : 응답 엔티티의 contene-length
혼합 로그 포맷 (기존 로그에서)
두개 추가
- Referer : 해당 URL을 요청자가 어디서 찾았는지에 관한 정보
- User-Agent : HTTP 클라이언트 애플리케이션이 무엇인지 알아볼 때 유용
다음. ... 서적은 무엇으로 할지 고민 중이다
'개발 > HTTP' 카테고리의 다른 글
| HTTP 강의 정리 (0) | 2022.04.07 |
|---|
