HTTP의 이해

＠ HTTP 등장 이전의 프로토콜

FTP(File Transfer Protocol)

NNTP(Network News Transfer Protocol)

Archie

WAIS(Wide Area Information Servers)

Gopher

등이 있다

＠ HTTP의 정의

HyperText Transfer Protocol

"약속" 클라이언트에서 서버까지 일련의 흐름을 결정

웹은 HTTP라는 약속을 사용한 통신으로 이루어져 있다!

＠ HTTP가 왜 널리 쓰이는가?

기업이나 조직 등의 방화벽 설정 문제: 지정된 프로토콜이나 포트 번호 이외의 패킷은 통과시키지 않는 기능이 있는데

이로 인해 새로운 프로토콜이나 포트 번호는 따로 설정을 해줘야 된다. 

많은 기업에서는 웹을 통해 액세스가 가능한데

서버 구축이나 웹 사이트에의 액세스를 할 때 방화벽 설정에서 기본적으로 HTTP(80/tcp)나 HTTPS(443/tcp)는 허가된 통신 환경일 것이다. 그러므로 따로 방화벽 설정이 필요없고 도입이 용이하며 

HTTP 클라이언트인 브라우저나 HTTP 서버가 많이 보급되어있는 점에서도

새로운 프로토콜을 만들지 않고 HTTP를 널리 쓰는 이유가 된다

＠ 웹의 탄생 배경

지식공유를 위해

WWW(World Wide Web)으로 HyperText로 여러 문서를 상호간에 관련 지어 공유

초창기의 WWW는 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션이었으나 현재는 일련의 시스템의 명칭으로 사용됨(웹이라 불림)

WWW를 구성하는 기술

HTML(HyperText Markup Language, SGML 베이스로 함)

HTTP(HyperText Transfer Protocol) 문서 전송 프로토콜

URL(Uniform Resource Locator) 문서의 주소를 저장하는 방법

＠ 웹의 발전

CERN(유럽 입자 물리학 연구소)

Mosaic

Netscape Navigator

Internet Explorer

Mozilla Firefox

Chrome, Opera, Safari

＠ TCP/IP 계층(4계층)

애플리 케이션 계층	HTTP, FTP, DNS
트랜스 포트 계층	데이터 흐름을 제공 TCP UDP 데이터를 작게 분해하여 상대방에게 보내고 정확하게 도착했는지도 확인 데이터를 확실하게 보냈는지 확인하기 위하여 Three way handshaking을 사용 (송신측 SYN->수신측 SYN/ACK->송신측 ACK)
네트워크 계층(IP)	패킷의 이동(전송하는 데이터의 최소 단위), 경로 설정(여러가지 선택지 중 하나의 길을 결정) IP주소(각 노드에 부여된 주소) MAC주소(네트워크 카드에 할당된 고유의 주소)를 사용 ARP(Address Resolution Protocol)을 사용하여 MAC 주소를 사용하여 여러 대의 컴퓨터와 네트워크 기기를 중계해서 상대방에게 도착한다 배송을 담당
링크 계층	하드웨어(디바이스 드라이버, 네트워크 인터페이스 카드)

＠ TCP / IP 통신의 흐름

클라이언트에서 시작	서버로 전달
HTTP 클라이언트(애플리케이션) ↓↑	HTTP 서버 ↑↓
TCP(트랜스포트) ↓↑	TCP ↑↓
IP(네트워크) ↓↑	IP ↑↓
네트워크(링크)                               ↔	네트워크

＠ 웹에서의 일련의 흐름

클라이언트가 DNS를 이용하여 도메인 이름을 이용해 접속할 사이트의 IP 주소 확인

↓

HTTP 메시지 작성

↓

TCP가 HTTP 메시지를 패킷으로 분해, 일련번호를 부여하여 전송

↓

IP가 상대 위치를 찾아가며 배송

↓

TCP가 상대방으로부터 받은 패킷을 조립(일련번호를 통해서)

↓

HTTP가 리퀘스트 처리

ps. 리퀘스트 처리 결과도 마찬가지로 TCP/IP 통신 순서대로 클라이언트에게 반환한다

＠ URI와 URL의 차이

인터넷 상에서 일반적으로 이루어지는 작업은 자원(resource)를 찾고 가져오는 일에 관련되어 있고

그 자원은 인터넷 상에 존재하는 HTML파일이나 이미지 파일 등을 의미

URL(Uniform Resource Locator) 해당 리소스의 정확한 위치정보

정형화 된 리소스의 위치표시

URL은 브라우저의 주소 창에 입력하는 주소를 의미

https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=URL+%EA%B3%B5%EB%B6%80

URL은 다음과 같은 내용으로 구성

프로토콜: http://

도메인: www.naver.com/

자원을 식별할 수 있는 자원의 경로명:  /search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=URL+%EA%B3%B5%EB%B6%80

위와 같은 URL을 통하여 인터넷 상의 자원을 지정

 

URI(Uniform Resource Identifier) 해당 리소스를 식별할 수 있는 식별정보

정형화 된 리소스 식별자 

URI는 리소스를 식별하는 문자열이라는 의미가 강하다 

Apache, IIS, Tomcat 등의 핸들러를 사용하기 때문에

HTTP 프로토콜, 호스트명,  포트번호를 제외하고 표시(완전한 full 주소는 아니지만 식별할 수 있다는 의미)

위의 예를 URI로 표시

/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=URL+%EA%B3%B5%EB%B6%80

인터넷 서비스를 전제로한 자원의 식별 체계

URL은 URI에 포함 URL ⊂ URI

＠ HTTP의 특징

리퀘스트 메시지: 메소드(POST, GET), URI, 프로토콜 버전, 헤더필드, 엔티티로 구성

리스폰스 메시지: 프로토콜 버전, 상태코드(200, 500, etc), 상태 코드 설명, 헤더필드, 바디로 구성

ps. 메소드로는 GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE 등이 존재한다(대표적으로 GET과 POST, HEAD 정도만 우선적으로 알아둘 것)

ps. 헤더필드란? 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타낸다

HTTP는 상태를 유지하지 않는다

장점: 많은 데이터를 매우 빠르고 확실하게 처리, 간단 명료

단점: 상태 유지가 필요한 경우 에로 사항 -> Cookie라는 기술이 도입(상태를 관리할 수 있게 됨)

Persistent Connections

HTTP 통신을 한 번 할 때마다 TCP에 의해 Three way handshaking을 통해 연결과 종료를 하던 것을 한 번 TCP 커넥션을 연결하고 나면 반복되는 리퀘스트와 리스폰스에서는 지속적으로 TCP가 연결되어있는 상태를 유지

(한쪽이 연결을 끊지 않을 때까지)

서버에 대한 부하, 오버헤드 감소

HTTP pipelining

리퀘스트 송신 후 리스폰스를 수신할 때까지 기다리던 것을 리스폰스를 기다리지 않고 병행해서 여러 리퀘스트를 보내고 여러 리스폰스를 받는 것이 가능

Cookie

stateless 프로토콜이라는 특징은 남겨두고 서버에서 리스폰스로 Set-Cookie를 통해 쿠키를 클라이언트에 보존하며 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키값을 넣어서 송신하여 자동으로 이전 상태를 확인 가능

＠ 여러가지 HTTP 메시지 

Content Codings - 메시지를 압축해서 전송

Chunked transfer Coding - 메시지를 분해해서 전송

Multipart - MIME(Multipurpose Internet Mail Extensions)를 이용해서 텍스트, 영상, 이미지와 같은 여러가지 데이터를 다

루기 위한 기능 사용

Range Request - 전체 리소스를 범위를 정해서 주고받는다->다운로드를 받던 중 커낵션이 끊어지면 처음부터 다시 다운

로드를 해야 했었으나 resume 기능을 통해 이전에 다운로드를 한 곳에서부터 다운로드 재개->206 Partial Content라는 리스폰스 상태 메시지로 돌아온다(서버가 Range Request를 지원하지 않는 경우 상태 코드 200 OK로 되돌아온다)

Content Negotiation - 같은 콘텐츠지만 여러 페이지를 지닌 웹 페이지에서 사용자마다 각각 다른 웹페이지를 보여준다

예를들면 Google 홈페이지 같은 경우 영어판 한국판 등등 다양한데 이것을 구현하는 방법으로 

Request 헤더 필드의 정보를 참고해서 자동적으로 처리하거나 클라이언트 측에서 수동으로 선택하거나 둘 다 지원하는

방식이 있다

(Request의 헤더필드에는 이와 관련한 Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language가 있다)

＠ HTTP 상태 코드

1xx Informational 리퀘스트를 받아들여 처리 중

2xx Success 리퀘스를 정상적으로 처리(성공)

3xx Redirection 리퀘스트를 완료하기 위해 추가 동작이 필요

4xx Client Error 서버가 리퀘스트 이해 불가능

5xx Server Error 서버가 리퀘스트 처리 실패

200 OK 정상 처리

204 No Content 클라이언트에 돌려줄 리소스가 없다, 클라이언트에서 서버에 정보를 보내는 것만 수행하고, 서버에서 받아올 필요가 없는 경우 사용

206 Partial Content 서버가 Range에 의해 부분적으로 GET 리퀘스트를 받았음을 나타냄, Content-Range와 같은 엔티티가 포함된다

301 Moved Permanently 요청한 페이지가 새 위치로 영구적으로 이동됨

302 Found 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용. 기존의 주소로 계속 접근 해야한다

303 See Other 302에러와 비슷하지만 Redirect 장소를 GET 메소드로 얻어야 한다고 명시

304 Not Modified 리소스는 있는데 조건이 맞지 않았다 3xx Error에 포함되지만 Redirect와는 관계가없다

요청한 리소스가 마지막 요청 이후 변경된 적이 없기 때문에 기존 클라이언트의 로컬 캐시 리소스를 사용하라고 한다

307 Temporary Redirect 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용할 것

400 Bad Request 서버가 요청한 것을 인식하지 못함

401 Unauthorized 권한이 없다

403 Forbidden 금지 됨, 액세스 거부

404 Not Found 리소스가 서버에 없다

500 Internal Server Error 리퀘스트 처리 도중 에러 발생

503 Service Unavailable 서버가 과부하 상태이거나 점검 중이어서 리퀘스트를 처리할 수 없는 상태

더 자세한 HTTP 상태 코드 정보는 이곳을 참조

＠ 가상 호스트

하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있게하는 것

물리적으로는 서버가 1대지만 가상으로 여러 대가 있는 것처럼 설정하는 것이 가능

＠ 통신 중계 프로그램

프록시

서버와 클라이언트의 양쪽 역할을 중계, 여러 프록시 서버를 경유하는 것도 가능

게이트웨이

다른 서버를 중계, HTTP 서버 이외의 서비스를 제공하는 서버와 통신

데이터베이스에 접속해 SQL 쿼리를 사용해서 데이터를 얻는 곳에 이용하거나 신용카드 결제 시스템 등과 연계할 때에도 사용

터널

서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속 주선

다른 서버와의 통신 경로 확립

＠ 캐시

프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본

서버에 리소스를 가지러가는 액세스를 줄이는 것이 가능해지면서 통신량과 통신 시간을 절약 가능

프록시가 서버로부터의 리스폰스를 중계할 때 프록시 서버 상에 리소스의 사본을 보존

캐시에도 유효기간이 있어서 캐시 서버나 클라이언트는 가지고있는 리소스가 유효한지 Origin 서버에 확인하거나 새로운 리소스를 획득하러 가야하기도 한다

클라이언트에서 사용하는 브라우저에서 가지는 캐시도 있는데 인터넷 익스플로러의 경우 인터넷 임시 파일이라고 부름

(브라우저가 유효한 캐시를 가지고 있으면 같은 리소스로의 액세스는 서버에 액세스하지 않고 로컬 디스크로부터 불러온다)

＠ HTTP 헤더 구성

리퀘스트 메시지 헤더는 리퀘스트 라인, 리퀘스트 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 구성

리스폰스 메시지 헤더는 상대 라인, 리스폰스 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 구성

헤더 필드는 헤더 필드 명: 필드 값으로 구성됨(ex. Content-Type:text/html)

일반 헤더 필드 목록

Cache-Control 캐싱 동작 지정

Connection

Date 메시지 생성 날짜

Pragma

Trailer

Transfer-Encoding 메시지 바디의 전송 코딩 형식 지정

Upgrade

Via 프록시 서버에 관한 정보

Warning 에러 통지

리퀘스트 헤더 필드 목록

Accept 유저 에이전트가 처리 가능한 미디어 타입

Accept-Charset 문자셋 우선 순위

Accept-Encoding 콘텐츠 인코딩 우선 순위

Accept-Language 언어(자연어)우선 순위

Authorization 웹 인증을 위한 정보

Expect 서버에 대한 특정 동작의 기대

From 유저의 메일 주소

Host 요구된 리소스의 호스트

If-Match 

If-Modified-Since

If-None-Match

If-Range

If-Unmodified-Since

Max-Forwards

Proxy-Authorization

Range

Referer

TE

User-Agent HTTP 클라이언트의 정보

리스폰스 헤더 필더 목록

Accept-Ranges 바이트 단위의 요구를 수신할 수 있는지 없는지 여부

Age 리소스의 지정 경과 시간

Etag

Location

Proxy-Authenticate

Retry-After

Server HTTP 서버 정보

Vary

WWW-Authenticate 서버의 클라이언트 인증을 위한 정보

엔티티 헤더 필드 목록

Allow 리소스가 제공하는 HTTP 메소드

Content-Encoding 엔티티 바디에 적용되는 콘텐츠 인코딩

Content-Language 엔티티의 자연어

Content-Length 엔티티 바디의 사이즈(단위: 바이트)

Content-Location

Content-MD5

Content-Range

Content-Type

Expires

Last-Modified

여기서 또 각 필드 명 마다 필드 값이 여러 개가 존재한다

＠ 쿠키와 관련된 헤더 필드

Set-Cookie 리스폰스

NAME=VALUE 쿠키에 부여된 이름과 값(필수)

Expires=DATE 쿠키 유효 기한(지정되지 않은 경우 브라우저를 닫을 때까지 유효)

Path=PATH 쿠키 적용 대상이 되는 서버 상의 디렉토리를 한정(지정하지 않은 경우 도큐먼트와 같은 디렉토리)

Domain=도메인 명 쿠키 적용 대상이 되는 도메인 명(지정하지 않은 경우 쿠키 생성한 서버의 도메인)

Secure HTTPS로 통신하고 있는 경우에만 쿠키를 송신

HttpOnly 쿠키를 JavaScript에서 액세스하지 못하도록 제한, XSS(크로스 사이트 스크립팅)으로부터 쿠키의 도청을 막는 것이 목적

Cookie 리퀘스트

서버로부터 수신한 쿠키를 이후의 리퀘스트에 포함해서 전달

쿠키를 여러 개 보내는 것도 가능

＠ HTTP의 단점(HTTPS의 등장 배경)

평문(암호화 되지 않은) 통신이기 때문에 도청이 가능하다(TCP/IP는도청 가능한 네트워크로 통신 내용을 엿볼 수 있다)

->암호화로 도청을 극복 가능

SSL(Secure Socket Layer) TLS(Transport Layer Security)와 같은 프로토콜을 조합함으로써 통신 내용을 암호화 가능

(SSL을 조합한 HTTP를 HTTPS(HTTP Secure)라고 부름))

or 콘텐츠 암호화

통신 상대를 확인하지 않으므로 위장 가능

->증명서를 통해 상대를 확인할 수 있다(SSL 사용). 신뢰할 수 있는 제 3자 기관에 의해 발행되는 증명서를 통해 입증한다

완전성을 입증할 수 없으므로 변조 가능

수신하는 내용이 도중에 변조된 내용일 수도 있다

->HTTPS를 통해 인증이나 암호화, 다이제스트 등의 기능을 사용

＠ HTTPS의 등장, HTTPS란 무엇인가

HTTP에 암호화나 인증 등의 구조를 더한 것을 의미

공개키 암호화 방식의 사용

공개키가 정확한지 아닌지를 증명하는 증명서의 사용: Certificate Authority 인증기관에서 발행하는 공개키 증명서 이용

(인증기관 ex. VeriSign)

＠ HTTPS의 단점

 

SSL을 사용함으로 처리가 느려진다(서버, 클라이언트 모두 암호화와 복호와 과정이 필요하므로 CPU나 메모리 등의 하드

웨어 리소스를 소비하게됨)

->결과적으로 서버 한 대당 처리할 수 있는 리퀘스트의 수가 줄어든다. 민감한 정보를 포함하지 않는 통신에서는 굳이 HTTPS를 사용해야할 이유가 없다(개인정보 등 민감한 정보를 다룰 때 사용)

증명서를 구입하는 비용(년간 수십만 원 정도 필요)

＠ 웹 콘텐츠에서 사용하는 기술

HTML

CSS

Dynamic HTML 

Web Application(CGI, Servlet)

XML

RSS/Atom

＠ DOM, Servlet, JSON 간단 정리

DOM(Document Object Model)이란

HTML 내의 요소를 오브젝트로 다루어서 요소 내의 문자열을 JavaScript 등의 스크립트를 사용하여 쉽게 추출하거나 조작할 수 있게 된다

(ex. JavaScript에서 document.getElementsByTagName 등을 이용해서 요소를 가져올 수 있다)

DOM의 여러 메소드를 이용하여 HTML 각 요소를 참조할 수 있다

CGI와 Servlet의 차이

CGI 개념 : Common Gateway Interface / 웹서버와 외부 프로그램을 연결하는 규약(일종의 프로토콜)

동적으로 웹페이지를 만들어주는 프로그램을 의미

Servlet 개념 : 자바를 사용하여 작성한 CGI 언어, 자바로 구현, JVM 안에서 Multi thread 로 동작

Servlet은 하나의 Process로 쓰레드를 생성하므로 과부하에 걸릴 확률이 적다

CGI방식과 Servlet 차이 : CGI는 다중 Process를 만들어 유저마다 Process를 적용하여 과부화에 걸리기 쉽다

JSON(JavaScript Object Notation)

경량화 되어있는 하나의 데이터 교환 방식

자바스크립트에서 문자열을 간단하게 읽어올 수 있다

XML이 사용되던 Ajax에서 JSON을 널리 이용하게 됨

간단하게 중괄호 안에 name:value의 형식을 가짐

{"name":"Web Application Security", "num":"TR001"}