그림으로 배우는 Http & Network Basic

Sep 12, 2021

책표지

그림으로 배우는 Http & Network Basic

책 소개

근 1년간 서버 셋팅을 하기도 하고 3년 넘게 웹개발을 하고있는데 네트워크에 대해 이론적으로 너무 모르고 있고 Http같은 경우 꼭 알아야 함에도 최소한의 정보 말고는 잘 모른다는것에 최근 부끄러움을 느낄때가 있었다.
유튜브에서 추천하는 분들이 있었고 책 후기에도 책에대한 칭찬이 많아 바로 구매하게 되었다. 네트워크 관련 내용들은 학교에서도 자격증을 취득하기 위해서도 공부했지만 항상 너무 어려웠는데 그림으로 얼마나 쉽게 설명해줄지 기대된다.

후기

제목만 보면 굉장히 쉬운 책일것 같은데 생각보다 어려웠다. 물론 네트워크나 서버를 다루시는 분들이라면 깊게 다루지 않는 책이 쉬워보일 수 있겠으니 일반적인 사람들은 어려울수도 있겠다고 느꼈다. 게다가 내용들중에 웹 개발자가 몰라도 될 내용까지 전부 다루는 느낌도 있어서 아쉬웠고 또 웹 개발자가 꼭 알아야 하는 부분을 깊게 다루던가 예를 들어 알려줬다면 좋았을 탠대 대상자가 웹 개발자가 아닌 정보통신쪽 전공자들이 아닌가 싶은 느낌이었다.

1. 웹과 네트워크에 대한 기본

HTTP

우리가 URL을 입력하면 해당 URL에 대한 화면이 출력된다. 이처럼 우리는 브라우저(클라이언트)를 통해 서버에 요청을 보내고 서버는 그에대한 응답을 해주는데 이런 클라이언트에서 서버까지 일련의 흐름을 결정하고 있는 것이 웹 HTTP라는 프로토콜이다.
프로토콜이란 약속을 의미하고 웹은 HTTP라는 약속을 사용한 통신으로 이루어져 있습니다.
최초의 인터넷은 자료를 보내기위해 하이퍼텍스트에 의해 상호간에 참조할 수 있는 WWW의 기본개념의 시스템이었다. WWW를 구성하는 기술은 문서기술로 HTML, 문서 전송 프로토콜로 HTTP, 문소의 주소를 지정하는 방법으로 URL 등이 제안되었다. HTTP/1.1은 1997년 1월에 공개되었고 현재 가장 많이 사용되는 버전이다. 이 당시에 주로 텍스트를 전송하기 위한 프로토콜이었지만 프로토콜 자체가 심플해서 여러 가지 응용 방법을 고려해 기능이 계속해서 추가되었다.

TCP/UDP

인터넷을 포함하여 일반적인 인터넷은 TCP/UDP라는 프로토콜에서 움직이고 있기 때문에 HTTP를 이해하기전에 TCP/UDP 프로토콜에 대한 이해를 해야한다.
클라이언트와 서버가 통신을 하기 위해선 서로 같은 방식으로 통신해야 하는데 통신 상대를 찾는 방법, 언떤 언어를 사용할건지 통신을 시작하는 방법과 종료하는 방법 같은 규칙들을 결정해야한다. 이렇게 서로 통신을 하기 위한 규칙들을 프로토콜이라 부른다.
인터넷과 관련된 프로토콜들은 TCP/IP라 부른다.
TCP/IP에서 중요한 개념은 계증인데 애플리케이션 계층, 트랜스포트 계층, 네트워크 계층, 링크 계층 4가지의 계층으로 나뉜다.

애플리케이션 계층 : 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다. TCP/IP에는 여러가지의 공통 애플리케이션이 있는데 FTP나 DNS도 포함되고 HTTP또한 이계층에 포함된다.
트랜스 포트 계층 : 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공한다. 트랜스포트 계층에는 서로다른 성질을 가진 TCP, UDP가 존재한다.
네트워크 계층 : 네트워크 상에서 패킷의 이동을 다룬다. 패킷은 전송하는 데이터의 최소단위를 의미한다. 상대방의 컴퓨터까지 도달하는 동안에 여러 네트워크 장치를 거치게 되는데 이런것을 설정해주는 계층이다.
링크 계층 : 네트워크에 접속하는 하드웨어적인 면을 다룬다.

통신의 흐름 HTTP 클라이언트 -> TCP -> IP -> 네트워크 -> 네트워크 -> IP -> TCP -> HTTP 서버 이런 과정속에 스택처럼 TCP에는 TCP헤더가 IP에는 IP헤더, 네트워크에는 이더넷 헤더가 붙고 서버에서는 반대로 사용된 헤더를 계층을 지나갈때마다 삭제한다. 이렇게 정보를 감싼는 것을 캡슐화라고 한다.

ip : 네트워크 계층에 해당하고 인터넷을 활용하는 대부분의 시스템이 IP를 이용하고 있다. IP는 프로토콜 명이지 IP주소와는 다르다. IP의 역할은 개별적인 패킷을 상대방에게 전달하는 것이다. 이렇게 상대방에게 전달하려면 여러 가지 정보가 필요한데 그 중 IP주소와 MAC주소가 가장 중요하다. IP주소는 각 노드에 주여된 주소를 가르키고 MAC 주소는 각 네트워크 카드에 할당된 고유 주소이다. IP주소는 변경이 가능하지만 MAC주소는 변경이 불가능하다. 송신할 떄 수신할 IP주소를 설정해준다면 이후 ARP프로토콜이 다음 경로의 MAC주소(라우터)를 찾아주고 해당 네트워크 장비로 이동해가면서 수신할 IP주소로 찾아간다. 결국 IP통신은 처음부터 전송할 경로를 알고 있는것이 아니라 대략적인 목적지만 알고 여러 네트워크 장비들을 거쳐 찾아가게 되는데 이런 과정을 라우팅이라고 한다.
TCP : 트랜스포트 계층에 해당한다. 특징으로는 신뢰성 있는 바이트 스트림 서비스를 제공하여 대용량의 데이터를 보내기 쉽게 작은 단위의 패킷으로 분해하여 상대방에게 보내고 정확하게 도착했는지 확인하는 역할을 하고있다. 데이터를 보내주는지 확인하는 과정을 쓰레웨이 핸드셰이킹이라 하는데 SYN, SYN/ACK, ACK 플래그들을 통해 확인하기 때문이다. 이 과정중에 통신이 끊긴다면 재전송한다.
DNS : HTTP와 같은 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공한다. DNS는 도메인명을 IP주소로 조사하거나 IP 주소로 부터 도메인명을 도사하는 역할을 한다.

URL과 URI

우리가 일반적으로 브라우저에서 입력하는 사이트 주소가 URL이다.
URI의 경우 Uniform Resource Identifiers의 약자이다.

Uniform : 통일된 서식을 결정하는 것, 여러 가지 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급할 수 있게 한다.
Resource : 리소스는 식별 가능한 모든 것을 의미한다. 도큐먼트 파일뿐 아니라 이미지와 서비스 등 다른 것과 구별할 수 있는 것은 리소스이다.
Identifier : 식별 가능한 것을 참조하는 오브젝트이며 식별자로 불립니다. 결국, URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자 입니다.

HTTP의 경우에는 http를 사용한다. 그 외에도 ftp, mailto, telnet, file 등이 있다.
URI는 리소스를 식별하기 위해 문자열 전반을 나타내는데 비해 URL은 리소스의 장소(네트워크 상의 위치)를 나타내고 URL은 URI의 서브넷이다.

URL포맷

http:와 https:같은 스키마를 사용하여 리소스를 얻기 위해 사용하는 프로토콜을 지시한다.

id:pw를 입력하여 자격정보를 입력할수도 있는데 이것은 옵션이고 실제로 사용해본적이 없다.

완전 수식 형식인 URI에서는 서버 주소를 지정할 필요가 있다. DNS이름 또는 IP주소를 입력해준다.

서버주소를 입력하였다면 뒤에 :를 입력한 후 포트를 입력할 수 있다. 이는 접속 대상이 되는 네트워크 포트 번호를 지정한다. 이것은 옵션으로 생략하면 보통 80포트가 동작한다.

파일의 경로 또는 서버의 컨트롤러에서 동작하는 매핑주소가 입력된다.

쿼리 문자열이 추가 되기도 하는데 ?변수명=값의 형태로 추가해주면 GET방식으로 데이터를 전송할 수 있다.

서브 리소스를 가리키기 위한 프래그먼트 식별자를 사용할 수 있는데 이는 옵션이다.

2. 간단한 프로토콜 HTTP

HTTP는 클라이언트와 서버간의 통신을 한다. HTTP는 클라이언트에서 서버로 리퀘스트를 보내면 그 결과를 서버는 리스폰스 해준다.

리퀘스트 : 서버에 요구하는 종류를 요구하는 메서드(GET,POST)가 포함되고 리소스의 위치인 URI가 포함된다. 또 HTTP의 버전이 포함되며 리퀘스트 헤더 필드와 엔티티가 포함된다.
리스폰스 : 리스폰스 또한 HTTP의 버전을 포함하고 있고 해당 요청에 대한 처리결과를 상태 코드와 상태코드에 대한 설명을 포함하고 있다. 또 리스폰스 헤더 필드와 바디로 구성되어있다.

HTTP는 상태를 저장하지 않기 때문에 사용자의 로그인 정보 같은것은 페이지마다 저장하여 넘길 수 없다. 때문에 세션이나 쿠키를 사용하여 정보를 저장해준다.

HTTP 메서드

GET : GET 메서드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구합니다. 개발에서 GET은 전송될 데이터가 노출되는 단점이 있지만 URI에 붙여서 보내는 편리함이 있어 노출해도 되는 데이터를 전송한다면 사용된다.
POST : POST 메서드는 엔티티를 전송하기 위해서 사용된다. 주로 회원가입, 로그인 같이 보호되야할 데이터가 있을 경우 사용된다.
PUT : PUT 메서드는 파일을 전송하기 위해 사용된다. 다만 PUT 자체에 인증 기능이 없어 누구든지 업로드가 가능하다는 보안 상의 문제가 있어 일반적으로 사용되지 않는다.
HEAD : HEAD 메서드는 GET과 같은 기능을 가지고 있지만 메시지 바디는 돌려주지 않는다. URI의 유효성이나 리소스의 갱신 시간을 체크하는 용도로 사용된다.
DELETE : DELETE메서드는 파일을 삭제하기 위해 사용된다. PUT과 같은 이유로 일반적으로는 사용되지 않으나 REST와 같이 사용되기도 한다.
OPTION : OPTIONS 메서드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메서드를 조사하기 위해 사용된다.
TRACE : TRACE 메서드는 웹서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킨다. 이것은 프록시 등을 중계하여 오리진 서버에 접속할 때 그 동작을 확인하기 위해서 사용되는데 거의 사용되지 않는다.
CONNECT : TCP 통신을 터널링 시키기 위해서 사용된다. 주로 SSL이랑 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용된다.

HTTP의 지속적 연결

초기 HTTP는 접속할 때마다 TCP연결을 하였다. 이는 초창기에 HTTP로 주고받는게 대부분 텍스트였기 때문인데 웹이 발전함에 따라 이미지들이 다수 포함되면서 쓸대없이 통신량이 늘어나기 시작했다.
이런 문제를 해결하기 위해 HTTP 1.0버전 이후 지속연결을 지원하여 한쪽에서 연결을 종료시키지 않는 이상 TCP연결을 지속시키도록 변경되었다. 지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 하여 리스폰스가 끝나지 않아도 리퀘스트를 여러번 보낼 수 있도록 할 수 있다.
지속연결이 가능하다고 해도 이전 연결에 대한 정보는 가져올 수 없어 매번 다시 접속해주어야 하는데 이를 해결하기 위해 쿠키를 사용할 수 있다. 쿠키는 클라이언트쪽에 저장되어 리퀘스트에 기존의 정보를 보내준다.

3. HTTP 정보는 HTTP 메시지에 있다

HTTP에서 교환하는 정보를 HTTP 메시지라고 부른다. 리퀘스트시에는 리퀘스트 메시지 리스폰스 할때는 리스폰스 메시지이다.
HTTP 메시지는 복수 행의 데이터로 구성된 텍스트 문자열이다. 또 메시지는 메시지 헤더와 메시지 바디로 구성되어있다. 처음으로 나오는 개행문자(CR+LF)로 둘을 구분할 수 있다.

메시지 헤더 : 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성

메시지 바디 : 꼭 전송되는 데이터 그 자체

메시지 헤더 구조

리퀘스트 라인(리퀘스트) : 리퀘스트에 사용하는 메서드와 리퀘스트 URI와 사용하는 HTTP버전이 포함
상태 라인(리스폰스) : 리스폰스 결과를 나타내는 상태코드와 상태코드에 대한 설명, HTTP 버전이 포함
헤더필드 : 리퀘스트와 리스폰스의 여러 조건과 속성등을 나타내는 각종 헤더 필드 포함(일반 헤더 필드, 리퀘스트 헤더 필드, 리스폰스 헤더 필드, 엔티티 헤더 필드)

인코딩

HTTP로 데이터를 전송할 경우 그대로 전송하는것도 가능하지만 인코딩을 함으로써 효율을 높일 수 있다.

메시지 : HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되고 통신을 통해서 전송된다.
엔티티 : 리퀘스트랑 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.

HTTP 메시지 바디의 역할은 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반하는 일인데 기본적으로 메시디 바디와 엔티티 바디가 같지만 전송 코딩이 적용되면 엔티티 바디의 내용이 변화한다.

콘텐츠 코딩 : 엔티티에 적용하는 인코딩을 가리킨다. 엔티티 정보를 유지한 채로 압축
청크 전송 코딩 : 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있는데 이런 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 부른다.

여러 데이터를 보내는 멀티파트

HTTP는 멀티파트에 대응하고 있어 하나의 메시디 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다. 주로 이미지나 문서 등을 업로드할 때 사용되고 있다.

mulitpart/form-datya : Web form으로부터 파일 업로드에 사용된다.
multipart/byteranges : 상태 코드 206 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용된다.

4. HTTP 상태 코드

상태 코드 클래스

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

2xx(Success) : 리퀘스트를 정상적으로 처리

3xx(Redirection) : 리퀘스트를 완료 하기 위한 추가 작업 필요.

4xx(Client Error) : 서버는 리퀘스트 이해 불가

5xx(Server Error) : 서버는 리퀘스트 처리 실패

200 : 성공
204 : 성공했으나 해당 리소스가 없는 상태
206 : 범위가 지정된 리퀘스트에 일부만 반환
301 : 해당 리소스에 새로운 URI가 부여되어 URI를 업데이트하라는 코드
302 : 301과 같지만 해당 리소스가 임시로 이동한 상태
303 : 302와 같지만 GET 메소드를 얻어야한다고 명시해줌
304 : 리소스에 대한 엑세스는 허락하지만 조건이 충족되지 않음
307 : 302와 같지만 POST에서 GET으로 치환하지 않는다.
400 : 리퀘스트 구문 에러
401 : HTTP 인증정보가 필요.
403 : 리소스에 대한 엑세스 거부
404 : 해당 리소스가 서버에 없음
500 : 서버에서 리퀘스트 처리 중 에러
503 : 서버가 과부하 중이거나 점검중

5. HTTP와 연계하는 웹 서버

HTTP/1.1 에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있도록 가상 호스트 기능을 사용하고 있다.

HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는것도 가능하다.

프록시

서버와 클라이언트의 양쪽 역할을 한다. 클라이언트로부터 리퀘스트를 서버에 전공, 서버로부터 리스폰스를 클라이언트에 전송한다.

캐싱 프록시 : 프록시로 리스폰스를 중계하는 때에 프록시 서버 상에 리소스 캐시를 보존하여 다시 같은 리소스를 요청할 때 서버가 아닌 캐시를 리턴해준다.
투명 프록시 : 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는다. 반대로 비투과 프록시가 있다.

게이트웨이

다른 서버를 중계하는 서버, 클라이언트로부터 수신한 리퀘스트를 리소스를 보유한 서버인 것처럼 수신한다. 클라이언트는 상대가 게이트웨이라는걸 알지 못하는 경우도 있다. 프록시와 유사하지만 HTTP 서버가 아닌 서버와 통신한다. 주로 결제, DB 쿼리호출에 사용된다.

터널

서로 떨어진 두대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램, 다른 서버와의 통신 경로를 확립한다. SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용된다.

6. HTTP 헤더

메시지 헤더는 클라이언트나 서버 처리에 필요한 중요 정보가 들어있고 메시지 바디에는 사용자와 리소스를 필요로 하는 정보가 있다.

HTTP 헤더 필드

HTTP 헤더 필드는 메시지 바디의 크기나 사용중인 언어, 인증 정보 등을 브라우저나 서버에 전달한다.
구조는 헤더 필드 명 : 필드 값 으로 구성되어 있다. 하나의 필드 명이 여러개의 필드 값을 가질 수 있는데 ,로 구분한다.

Connection 헤더 필드

Connection 헤더 필드는 두가지 역할을 한다.

프록시에 더 이상 전송하지 않는 헤더 필드를 저장
지속적 접속 관리

Date

Date 헤더 필드는 HTTP 메시지를 생성한 날짜를 나타낸다.

Trailer

메시지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있다. 청크 전송 인코딩을 사용하고 있는 경우에 사용 가능하다.

Transfer-Encoding

메시지 바디의 전송 코딩 형식을 지정하는 경우 사용

Upgrade

HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우 사용

Via

클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해서 사용된다. Via 헤더 필드는 전송된 메시지의 추적과 리퀘스트 루프의 회피 등에서 사용되기 때문에 프록시를 경우하는 경우 반드시 부가해야한다.

Warning

리스폰스에 관한 추가 정보를 전달하는데 그 내용은 기본적으로 캐시에 관한 경고를 전달해준다.

리퀘스트 헤더 필드

클라이언트 -> 서버 송신된 리퀘스트 메시지에 사용되는 헤더로 리퀘스트의 부가 정보, 클아이언트의 정보, 리스폰스 콘텐츠에 관한 우선순위가 포함된다.

Accept : 유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Charset : 유저 에이전트에서 처리할 수 있는 문자셋으로, 문자셋의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Encoding : 유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용
Accept-Language : 유저 에이전트가 처리할 수 있는 자연어의 세트와 자연어 세트의 상대적인 우선순위를 전달하기 위해 사용 Authorization : 유저 에이전트의 인증정보(크리덴셜 값)을 전달하기 위해서 사용된다.
Expect : 클라이언트가 서버에 특정 동작 요구를 전달, 서버가 응답하지 못할 경우 상태코드 417코드를 반환
From : 유저 에이턴트를 사용하고 있는 유저의 메일 주소를 전달
Host : 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다. HTTP/1.1에서 유일한 필수 헤더 필드이다. 이는 하나의 IP에 복수 도메인이 적용되어 있을때 이를 체크하기 위한 호스트명을 넣어준다.
if-xxx : 조건부 리퀘스트로 if-뒤에 붙는 종류에 따라 지정된 조건에 맞는 경우에만 리퀘스트를 받는다.
Max-Forwards : 리퀘스트를 할 때에 전송해도 좋은 서버 수의 최대치를 10진수로 지정할 수 있다. 서버를 지나갈때마다 1씩 빼서 0이되면 리스폰스해준다.
Proxy-Authorization : 프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트 정보를 전달한다.
Range : 리소스의 일부분만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다. 리퀘스트를 처리 할 수 있는 경우 상태코드 206을 반환하고 처리할 수 없다면 200을 반환한다.
Referer : 리퀘스트가 발생한 본래 리소스의 URI를 전달한다. 기본적으로 Referer 헤더 필드는 전송되어야 하지만 브라우저 주소창에 직접 입력하거나 보안상 바람직하지 않다고 판단하면 보내지 않아도 된다. 리소스 URI 쿼리에 ID와 PW가 들어있다면 Referer을 통해 다른 서버에 누설 될 수 있다.
TE : 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선순위를 전달합니다.
User-Agent : 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드

리스폰스 헤더 필드

서버 측으로부터 클라이언트 측으로 송신되는 리스폰스 메시지에 적용된 헤더

Accept-Ranges : 서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 전달
Age : 얼마나 오래 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달한다. 필드 값의 단위는 초이다.
ETag : 엔티티 태그라고도 불리며 임의적으로 리소스를 특정하기 위한 문자열을 전달한다. 서버는 리소스마다 ETag 값을 할당한다.
Location : 리스폰스의 수신자에 대해서 Request-URI 이외의 리소스 엑세스를 유도하는 경우에 사용
Proxy-Authenticate : 프록시 서버에서의 인증 요구를 클라이언트에 전달
Retry-After : 클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지를 전달합니다.
Server : 서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달
Vary : 캐시를 컨트롤하기 위해 사용, 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달한다.
WWW-Authenticate : HTTP 엑세스 인증에 사용, Request-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마와 파라미터를 나타내는 challenge를 전달

엔티티 헤더 필드

Allow : Request-URI에 지정된 리소스가 제공하는 메소드의 일람을 전달, 서버가 받을 수 없는 메소드를 호출한 경우 405코드와 함께 수신 가능한 메소드들을 기록한 Allow 헤더 필드를 반환한다.
Content-Encoding : 서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달
Content-Language : 엔티티 바디에 사용된 자연어를 전달
Content-Length : 엔티티 바디의 크기를 전달한다.
Content-Location : 메시지 바디에 대응하는 URI를 전달, 메시지 바디로 반환된 리소스의 URI를 나타낸다.
Content-MD5 : 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다.
Content-Range : 범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해서 리스폰스를 할 때에 사용된다.
Content-Type : 엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달, Charset 파라미터는 문자셋을 지정한다.
Expires : 리소스의 유효 기한 날짜를 전달
Last-Modified : 리소스가 마지막으로 갱신되었던 날짜 정보를 전달

쿠키를 위한 헤더필드

쿠키는 유저 식별과 상태 관리에 사용되고 있는 기능이다. 유저의 컴퓨터 상에 일시적으로 데이터를 기록하고 서버에 엑세스하 해 왔을 때 쿠키를 송신한다. 쿠키가 호출될때는 유효 기한과 송신지의 도메인, 경로, 프로토콜 등을 체크하기 때문에 도난당하는일은 없다.

Set-Cookie : 서버가 클라이언트에 대해 상태관리를 시작할 때 다양한 정보를 전달한다. Expires를 통해 유효 기한을 조정할 수 있고 domian속성을 통해 호출될 도메인을 설정할 수 있다.(뒤가같은 도메인에 넘겨줄 수 있어 위험) Secure 속성을 사용하여 HTTPS에서만 호출할 수 있도록 할 수 있다. HTTPOnly속성을 통해 JS를 경유해서 쿠키를 취득하지 못하도록 할 수 있다.
Cookie : HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후에 리퀘스트에 포함하여 전달

그 외 헤더 필드

X-Frame-Option, X-XSS-Protection, DNT, P3P

7. HTTPS

HTTP의 단점

암호화 하지 않았기 때문에 도청의 위험이 있다

HTTP를 사용한 리퀘스트나 리스폰스 통신에는 암호화 하는 기능이 없다. 이는 TCP/IP 구조의 통신은 통신 경로의 도중에 엿볼 수 있기 때문에 매우 위험하다. 클라이언트와 서버가 통신을 할때 다이렉트로 연결되지 않고 여러 통신경로를 거치기 때문에 중간에 가로챌수도 있고 네트워크상에서 패킷을 수집하여 가로챌수도 있다.
이런 위험을 방지하고자 HTTP 프로토콜에 SSL이나 TLS 프로토콜을 조합함으로써 통신내용을 암호화 할 수 있는데 이를 HTTPS라고 부른다.
이 외에도 HTTP 환경에서 서버에서 컨텐츠를 암호화 하고 클라이언트에서 복호화하는 방법이 있는데 일반적으로는 사용되기 어렵다.

통신 상대를 확인하지 않기 때문에 위장 가능

HTTP를 사용할 경우 리퀘스트가 도달하는 서버가 고객이 진짜 원했던 서버인지 리스폰스가 도달해야하는 곳이 진짜 클라이언트가 있는곳인지 확인할 수 없다. 즉 서버와 클라이언트를 속임으로써 다른곳으로 보내질 수 있는 위험이 있다. 이 또한 SSL에서 지원하는 인증서 기능으로 상대를 확인할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능

리퀘스트하여 서버로 가는 데이터나 리스폰스 되어 클라이언트로 돌아가는 데이터를 중간에 누군가 가로체어 변조를 한 후 원래 경로로 전달했을 때 검증을 할 방법이 없다. 아직까지 이를 해결할 완벽한 방법은 존재하지 않고 해시값을 사용하여 검증하거나 디지털 서명을 하는 방식을 활용하여 결제같은 주요 기능에만 변조를 막는 방법이 있다.

HTTPS

SSL을 덮어쓴 HTTP

HTTPS는 HTTP에서 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체하고 있다.
보통 HTTP는 TCP와 직접 통신을 하지만 HTTPS의 경우 HTTP가 SSL과 통신을 하고 SSL이 TCP와 통신을 하게된다.

공개키 암호화 방식

통신을 할 때 하나의 키로 관리 된다면 위험성이 높겠지만 HTTPS는 공개키, 비밀키 페어로 관리되며 공개키를 보내 암호화를 하고 그 암호화된 데이터를 복호화하는 방법인 비밀키는 보내지 않음으로써 돌아오지 않는 데이터는 복호화가 불가능해 안전하다.

증명서

공개키, 비밀키 페어의 방식에도 문제가 있는데 애초에 전달하는 공개키에 변조가 있을 경우이다. 이를 방지하고자 제 3의 기관에 인증을 받고 해당 공개키에 디지털 서명을 하여 클라이언트가 해당 공개키가 인증서를 받은 증명된 공개키라는 것을 확인할 수 있다.

단점

HTTPS를 사용할 경우 HTTP에 비하여 2배에서 100배까지 느릴 수 있다. 리퀘스트와 리스폰스 외에 SSL과 통신을 추가하였기 때문에 통신의 과정에서 지연이 되고 데이터를 암호화와 복호화 하기 때문에 그만큼 CPU와 메모리의 리소스를 사용하게 되어 짧은시간에 여러번 엑세스하는 작업을 할 경우 매우 효율이 떨어질 수 있다.
또 증명서가 필요하기 때문에 신뢰성 있는 기관의 증명서가 필요한데 추가적인 비용이 발생한다.

8. 누가 액세스하고 있는지 확인하는 인증

인증

클라이언트가 서버에 본인이 누구한태 알려줄 때 이름만 밝힌다면 조작된 데이터인지 알 수 없다. 이런 정보를 확인하기 위해 사용되는것이 password, 토큰, 전자 증명서, 생체인식(지문,얼굴,홍체), IC카드 등이 있다.

HTTP에서 사용하는 인증 방법

BASIC : 인증에 필요한 리소스에 리퀘스트가 있을 경우 서버가 상태코드 401코드를 리스폰스해주고 클라이언트는 인증 정보를 Base64로 전송하는 방식으로 이는 암호화가 아니어서 안전하지 않아 거의 사용하지 않는다.
DIGEST : BASIC의 약점을 보완한 방식으로 챌린지 리스폰스 방식으로 상대방이 보낸 챌린지 코드를 사용하여 리스폰스를 계산한다. 하지만 이 역시 HTTPS에 비해 부족하며 위장을 방지할 수 없기 때문에 거의 사용되지 않는다.
SSL 인증 : 앞에 단원에서 설명한 방식으로 안전하나 리소스를 많이 이용하고 비용이 발생한다.
폼 베이스 인증 : HTTP에 등록되어진 방법이 아닌 서버에서 만들어진 로직대로 정보를 등록하여 인증하는 방식으로 가장 일반적이다.(회원가입, 로그인 방식)

9. HTTP에 기능을 추가한 프로토콜

HTTP 프로토콜은 오래 되었기 때문에 제한이나 한계가 있다. 특히 최근에는 SNS같은 수많은 접속자가 수많은 데이터를 올리고 받아오는 작업들을 HTTP만으로는 빠르게 처리할 수 없다.
병목현상이 생기는 이유

1개의 커넥션에 1개의 리퀘스트만 가능
리퀘스트는 클라이언트가 이벤트를 해야 가능하다.
리퀘스트/리스폰스에서 메시지는 압축되지 않아 많은 데이터를 전송하는데 효율적이지 못하다.
헤더에 들어가는 필드들이 너무 많다.

AJAX

javascript를 이용하여 웹 페이지의 일부분만 사용하는 비동기 통신방식이다. 일부부만 갱신되어 기존의 동기식 통신에 비해 전송되느 데이터를 줄일 수 있다.

Comet

서버측에서 콘텐츠의 변경이 있을 경우 클라이언트의 리퀘스트를 기다리지 않고 전송한다. 실시간 갱신은 가능하지만 커넥션을 유지하는 시간이 길어져 리소스를 소비한다.

SPDY

구글이 발표한 기술로 병목현상의 개선을 프로토콜 레벨에서 해결하기 위한 개발중인 프로토콜이다. 트랜스포트 계층과 TCP/IP 계층 사이에 세션 계층을 추가하는 형태로 동작한다. 기존에 HTTP만 사용할때보다 장점은 HTTP 리퀘스트를 무제한으로 처리하기 때문에 한번의 접속으로 효율이 높다. 또한 이렇게 무제한으로 오는 리퀘스트에 우선순위를 할당할 수 있어 중요한 리퀘스트부터 처리가 가능하다. 또 무제한 처리를 할 경우 헤더의 용량이 커 부하가 갈 수 있는데 압축을 지원한다.
이 외에도 서버가 클라이언트에게 리퀘스트를 받지 않고 푸시해주는 기능과 리퀘스트할 리소스를 제안하는 기능도 추가된다.

WebSocket

서버와 클라이언트가 한번 접속을 하면 그 뒤의 통신은 모두 전용 프로토콜로 하는 방식이다. 접속을 유지하기 때문에 서버에서 클라이언트로 먼저 요청할 수 있고 자주 접속을 시도하는 오버헤드를 줄일 수 있다.

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

HTML

웹 상에서 하이퍼텍스트를 보내기 위해서 개발된 언어, 2014년 HTML5가 발표되었다. 브라우저 별로 버전이 달라 규격이 통일되지 않은 문제가 있다.

CSS

HTML 요소들을 어떻게 표시할지 지시하는 것으로 스타일 시트라고 불린다.

Javascript

웹 페이지를 동적으로 변경해준다. DOM을 사용하여 HTML내의 요소를 오브젝트로 다룬다.

웹 어플리케이션

CGI는 웹 서버가 리퀘스트를 프로그램에 전달하기 위한 구조로 CGI를 사용하는 프로그램으로는 PHP, Ruby 등이 있다. 서블릿은 서버 상에 HTML 등의 동적 컨텐츠를 생성하기 위한 프로그램인데 Java에서 사용한다.

데이터 송수신용 언어

XML은 목적에 맞게 확장 가능한 범용적인 마크업 언어이다. HTML과 비슷하지만 Tag를 사용자가 커스트마이징하여 사용한다. RSS/Atom은 블로그나 뉴스의 갱신 정보를 송신하기 위한 문서 포맷의 총칭으로 XML을 사용한다.
JSON은 Javascript의 Object로 단순한 형태로 되어있기 때문에 가볍게 빠르게 보낼 수 있고 브라우저에서 쉽게 작업할 수 있다.

11. 웹 공격 기술

HTTP는 보안 상의 문제가 일어날 정도로 복잡한 프로토콜이 아니기 때문에 공격 대상이 되는 경우는 거의 없다. HTTP를 사용하는 서버와 클라이언트 그리고 서버 상에서 동작하는 APP이나 리소스 등이 공격받는다.
HTTP에는 보안 기능이 없기 때문에 웹 애플리케이션에서 개발자가 설계하고 구현해야 한다. 이런 공격의 경우 리퀘스트를 통해 실행되며 특정 데이터를 빼가거나 권한 자체를 뺏는 일들이 발생할 수 있다.

서버를 노리는 능동적 공격

공격자가 직접 웹 APP에 엑세스하여 공격 코드를 보내는 타입의 공격이다. 대표적으로 SQL 인젝션과 OS 커맨드 인젝션이 있다.

유저를 노리는 수동적 공격

유저를 함정으로 유도하는 방법으로 공격자는 함정을 만들고 유저가 해당 함정에 리퀘스트하도록 유인한다. 이후 리퀘스트를 할 경우 공격코드를 통해 유저의 데이터에 접근하거나 권한을 뺏어온다. 대표적으로 크로스 사이트 스크립팅과 크로스 사이트 리퀘스트 포저리 등이 있다.

백엔드에서 유효성 체크

JS를 이용한 프런트엔드에서의 체크는 사용자에게 실수를 지적해주는 정도로 사용해야 하고 백엔드 단에서 체크를 해주어야 한다. 이는 공격자가 프런트단을 통하지 않고 바로 리퀘스트로 공격할 수도 있기 때문이다.

크로스 사이트 스크립팅

XSS는 취약성이 있는 웹 사이트를 방문한 사용자의 브라우저에서 부정한 HTML 태그나 JS 등을 동작시키는 공격입니다. 동적으로 HTML을 생성하는 부분에서 취약성이 발생할 수 있다. 이는 공격자가 작성한 스크립트가 함정이 되고 유저가 브라우저 상에서 움직이는 수동적 공격이다.

가짜 입력폼에 의해 개인정보를 가져간다.
스크립트에 의해 쿠키 값을 가져간다.

SQL 인젝션

웹 APP을 이용하고 있는 DB에 SQL을 부정하게 실행하는 공격으로 개인 정보나 기밀 정보가 누설될 수 있다. 만약 SQL의 호출 방법에 미비가 있을 경우 의도하지 않는 SQL문이 삽입될 수 있다.

DB내의 데이터를 열람하거나 변조
인증 회피
DB 서버를 경유한 프로그램 실행