웹과 네트워크의 기본에 대해 알아보자

웹은 HTTP로 나타낸다

  • 웹 브라우저는 웹 브라우저 주소 입력란에 지정된 URL에 의지해서 웹 서버로부터 리소스라고 불리는 파일 등의 정보를 얻는다.
  • 서버에 의뢰하는 웹 브라우저 등을 클라이언트라고 부른다.
  • 클라이언트에서 서버까지 일련의 흐름을 결정하고 있는 것은 웹에서 HTTP라고 불리는 프로토콜이다.
  • 프로토콜이라는 의미는 “약속”이다.

HTTP는 이렇게 태어났고 성장했다

  • 1989년에 CERN의 팀 비너스 리 박사는 멀리 떨어져 있는 동료 연구자와 지식을 공용하게 할 수 있도록 시스템을 고안하였다. 최초로 고안한 것은 여러 문서를 상호간에 관련 짓는 하이퍼텍스트에 의해 상호간에 참조할 수 있는 WWW의 기본 개념이 되었다.
  • 이러한 WWW를 구성하는 기술로서, 문서 기술 언어로는 SGML을 베이스로 한 HTML, 문서 전송 프로토콜로는 HTTP, 문서의 주소를 지정하는 방법으로 URL이 제안되었다.
  • WWW는 그 당시에는 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션의 명칭이었지만, 지금은 일련의 시스템 명칭으로 사용되어 웹(Web)이라 불리고 있습니다.
  • 1993년에 NCSA에서 현재 사용하는 웹브라우저의 선조라고 말할 수 있는 모자이크를 개발했다.
  • 1994년에 넷스케이프 사에서 넷스케이프 내비게이터 1.0을 출시하고 1995년에 마이크로소프트 사에서 인터넷 익스플로러 1.0과 2.0을 출시했다. 1995년 경부터 두 회사의 브라우저 경쟁이 과열되어 독자적으로 HTML을 확장해나가서 지금도 HTML 콘텐츠를 만드는 유저들을 곤란하게 만들었다.
  • 진보 안하는 HTTP
    • HTTP/0.9 1990년에 등장했는데, 이 당시 정식 사양서가 아니었다. 이 당시 등장한 HTTP는 1.0 이전이라는 의미엣허 HTTP/0.9fkrh qnffjTek.
    • HTTP/1.0 1996년 5월에 정식 사양으로 공개되었다. 초기의 사양이지만 현재에도 아직 많은 서버상에서 현역으로 가동된다.
    • HTTP/1.1 1997년 1월에 공개된 버전으로 현재 가장 많이 사용되는 버전이다. 현재 차세대를 담당할 HTTP/2.0이 책정되어 있지만 널리 사용되기까지는 아직 시간이 걸릴것이다.
    • HTTP는 등장 당시에는 주로 텍스트를 전송하기 위한 프로토콜이었지만, 프로토콜 자체가 상당히 간단해서 여러가지 응용 방법을 고려해 기능이 계속해서 추가되었다. 지금은 웹이라는 틀을 넘어서 다양하게 사용되는 프로토콜이 되었다.

네트워크의 기본은 TCP/IP

  • 서로 다른 하드웨어와 운영체제 등을 가지고 서로 통신을 하기 위해서는 모든 요소에 규칙이 필요하게된다. 이러한 규칙을 프로토콜이라고 부른다.
  • 프로토콜에는 케이블 규격, IP 주소 지정 방법, 떨어진 상대를 찾기 위한 방법, 그곳에 도달하는 순서, 웹을 표시하기 위한 순서 등이 있다.
  • 이렇게 인터넷과 관련된 프로토콜들을 모은 것을 TCP/IP라고 부른다. 일반적으로 IP 프로토콜을 사용하는 통신에서 사용되고 있는 프로톨콜들 총칭해서 TCP/IP라는 이름이 사용된다.
  • TCP/IP는 애플리케이션 계층, 프랜스포트 계층, 네트워크 계층, 링크 계층 이렇게 4계층으로 나뉘어 있다.
  • TCP/IP가 계층화 되어 있는 이유는 사양이 변경되면 변경된 해당 계층만 바꾸면 되기 때문이다. 또한, 설계를 할 때 해현재 설계중인 계층만 고려하면 되기 때문에 쉬워진다.
    • 애플리케이션 계층: 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정한다. FTP, DNS, HTTP 등이 있다.
    • 트랜스포트 계층: 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이에 데이터 흐름을 제공한다. TCP, UDP 두 가지 프로토콜이 있다.
    • 네트워크 계층(인터넷 계층): 네트워크 상에서 패킷의 이동을 다룬다. 패킷이란 전송하는 데이터의 최소 단위다. 이 계층에서는 어떤 경로를 거쳐 상대의 컴퓨터까지 패킷을 보낼지 결정한다.
    • 링크 계층(데이터 링크 계층, 네트워크 인터페이스 계층): 네트워크에 접속하는 하드웨어적인 면을 다룬다. 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버랑 NIC를 포함한다. 그리고 케이블과 같은 물리적으로 보이는 부분도 포함한다.
  • TCP/IP로 통신을 할 때 계층을 순서대로 거쳐 상대와 통신한다. 송신하는 측은 애플리케이션 계층에서부터 내려가고, 수신하는 측은 애플리케이션 계층으로 올라간다.
    • 송신
      • 애플리케이션 계층(HTTP): 어느 웹페이지를 보고싶다는 HTTP 리퀘스트를 지시한다.
      • 트랜스포트 계층(TCP): 애플리케이션 계층에서 받은 데이터를 통신하기 쉽게 조각내어 안내 번호와 포트 번호를 붙여 네트워크 계층에 전달한다.
      • 네트워크 계층(IP): 수신지 MAC 주소를 추가해서 링크 계층에 전달한다.
    • 수신: 링크 계층에서 받아들여 순서대로 위의 계층에 전달하여 애플리케이션 계층까지 도달한다.
  • 각 계층을 거칠 때는 반드시 헤더로 불려지는 각 계층에 필요한 정보를 추가한다. 반대로 수신측에서는 각 계층을 거칠 때마다 반드시 해당 계층에 사용한 헤더를 삭제한다. 이렇게 정보를 감싸는 것을 캡슐화라고 부른다.

HTTP와 관계가 깊은 프로토콜은 IP/TCP/DNS

  • IP는 네트워크 계층에 해당한다. 인터넷을 활용하는 거의 대부분의 시스템이 IP를 이용하고 있다.
  • IP의 역할은 개개의 패킷을 상대방에게 전달하는 것이다. 상대에게 전달하기위해 IP주소와 MAC주소가 필요하다. IP 주소는 각 노드에 부여된 주소를 가리키고 MAC주소는 각 네트워크 카드에 할당된 고유의 주소다. IP 주소는 변경 가능하지만 기본적으로 MAC 주소는 변경할 수 없다.
  • IP 통신은 MAC 주소에 의존해서 통신한다.
  • 여러 대의 컴퓨터와 네트워크 기기를 중계해서 상대방에게 도착한다. 그렇게 중계하는 동안에는 다음으로 중계할 곳의 MAC 주소를 사용하여 목적지를 찾아가는 것이다. 이떄, ARP라는 프로토콜을 사용한다. ARP는 IP주소를 바탕으로 MAC 주소를 조사할 수 있다.
  • 목적지까지 중계를 하는 도중에 컴퓨터와 라우터 등의 네트워크 기기는 목적지에 도착하기까지 대략적인 목적지만 알고있지, 인터넷 전체를 상세하게 파악하지는 못한다.
  • TCP는 트랜스포트 계층에 해당한다. 신뢰성 있는 바이트 스트림 서비스를 제공한다.
  • 바이트 스트림 서비스란 용량이 큰 데이털르 보내기 쉽게 TCP 세그먼트라고 불리는 단위 패킷으로 잘게 분해하여 관리하는 것을 말한다.
  • TCP는 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 경ㄱ할을 담당하고 있다.
  • TCP는 상대에게 확실하게 데이터를 보내기 위해서 three way handshaking이라는 방법을 사용한다.
  • 이 방법은 송신측에서 최초 ‘SYN’플래그로 상대에게 접속함과 동시에 패킷을 보내고, 수신측에서 ‘SYN/ACK’ 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 전한다. 마지막으로 송신측이 ‘ACK’ 플래그를 보내 패킷 교환이 완료되었음을 전한다.

이름 해결을 담당하는 DNS

  • DNS를 통해 컴퓨터는 IP 주소아는 별도로 호스트 이름과 도메인 이름을 붙일 수 있다.
  • DNS는 도메인명에서 IP 주솔르 조사하거나 반대로 IP 주소로부터 도메인명을 조사하는 서비스를 제공하고 있다.

URI와 URL

  • URI는 Uniform Resource Identifier의 약자다.
  • Uniform: 통일된 서식을 결정하는 것으로, 여러 가지 종류의 리소스 지정 방법을 같은 맥락에서 구별없이 취급할 수 있게 한다. http아 ftp 등의 스키마를 도입할 수 있게한다.
  • Resouece: 식별 가능한 모든 것. 도큐먼트 파일뿐만 아니라 이미지나 서비스(예, 오늘의 일기 예보) 등 다른 것과 구별할 수 있는 것은 모두 리소스다. 리소스는 복수의 집합도 파악할 수 있다.
  • Identifier: 식별 가능한 것을 참조하는 오브젝트이며 식별자라고 부른다. 결국 URI는 스키마를 나타내는 리소스를 식별하기 위한 식별자다.
  • URI는 리소스를 식별하기 위해 문자열 전반을 나타내는데 비해 URL은 리소스의 장소(네트워크 상의 위치)를 나타냅니다.
  • URL 포맷
    • 스키마: 리소스를 얻기 위해 사용하는 프로토콜을 지시한다. 예시: ‘http:’, ‘https:’
    • 자격정보(크리덴셜): (optional) 서버로부터 리소스를 취득하려면 자격정보가 필요하다. 유저명과 패스워드를 지정할 수 있다. 예시: user:pass
    • 서버 주소: DNS이름이나 IPv4 주소나 IPv6주솔르 대괄호로 묶어서 지정한다. 예시: ‘192.168.1.1’, ‘www.hackr.jp’, ‘[0:0:0:0:0:0:0:1]’
    • 서버 포트: (optional) 서버의 접속 대상이 되는 네트워크 포트 번호를 지정한다. 생략하면 디폴트 폰트가 사용된다. 예시: ‘:80’
    • 계층적 파일 패스: 특정 리소스를 식별하기 위해서 서버 상의 파일 패스를 지정한다. 예시: ‘/dir/index.htm’
    • 쿼리 문자열: (optional) 파일 패스로 지정된 리소스에 임의의 파라미터를 넘겨주기 위해서 쿼리 문자열을 상요한다. 예시: ‘uid=1’
    • 프래그멘트 실별자: (optional)취득한 리소스에 서브 리소스(도큐먼트 중간에 위치)를 가리키기 위해서 프래그맨트 식별자가 사용된다. 예시: ‘#ch1’

간단한 프로토콜 HTTP

HTTP는 클라이언트와 서버 간에 통신을 한다

  • 텍스트나 이미지 같은 리소스를 필요하다고 요구하는 쪽이 클라이언트가 되고, 이러한 리소스를 제공하는 쪽이 서버가 된다.
  • HTTP는 클라이언트와 서버의 역할을 명확하게 구별하고 있다.

리퀘스트와 리스폰르르 교환하여 성립

  • HTTP는 클라이언트로부터 request를 송신되며, 그 결과가 서버로부터 response가 되돌아온다.

  • request

      GET /index.html HTTP /1.1
  Host: www.hackr.jp
    • “GET”: 메서드라고 부른다. 서버에 요구하는 종류다.
    • “/index.html”: URI. 요구 대상인 리소스를 나타낸다.
    • “HTTP /1.1”: HTTP 버전 번호. 클라이언트 기능을 식별하기 위해서 있다.
    • 그 외에 레퀘스트 헤더 필드와 엔티티가 있다.

  • response

      HTTP /1.1 200 OK
  Date: Tue, 10 Jul 2012 06:50:15 GMT
  Content-Length: 362
  Content-Type: text/html

  <html>
  ...
    • “HTTP /1.1”: 서버의 HTTP 버전
    • “200 OK”: 리퀘스트의 처리 결과를 나타내느 상태 코드와 설명.
    • “Date:… … text/html”: 헤더 필드
    • “<html>…”: body라고 불리는 리소스 본체.

HTTP는 상태를 유지하지 않는 프로토콜

  • HTTP는 상태를 유지하지 않는 stateless 프로토콜이다. HTTP 프로토콜 독자적으로, request와 response를 교환하는 동안에 상태를 관리하지 않는다. 결국, HTTP 프로토콜 레벨에서는 이전에 보냈던 request나 response를 기억하지 못한다.
  • 하지만 웹이 진화함에 따라 로그인 상태 등의 상태 관리가 필요해졌다. 이를 위해 쿠키라는 기술이 도입되었다. 쿠키로 인해 HTTP를 이용한 통신에서도 상태를 계속 관리할 수 있게 되었다.

리퀘스트 URI로 리소스를 식별

리퀘스트 URI를 지정하는 방법에는 여러 종류가 있다.

  • 모든 URI를 리퀘스트 URI에 포함한다.

      GET http://hackr.jp/index.htm HTTP/1.1

  • Host 헤더 필드에 네트워크 로케이션을 퐇마한다.

      GET /index.htm HTTP/1.1
  Host: hackr.jp

  • 특정 리소스가 아닌 서버 자신에게 리퀘스트를 송신하는 경우에는 URI에 [*]을 지정할 수 있다.

메소드를 사용하여 지시를 내리다

메소드 설명 제공하고 있는 HTTP 버전
GET 리소스 취득 1.0 1.1
POST 엔티티 바디 전송 1.0 1.1
PUT 파일 전송 1.0 1.1
HEAD 메시지 헤더 취득 1.0 1.1
DELETE 파일 삭제 1.0 1.1
OPTIONS 서포트하고 있는 메소드 문의 1.1
TRACE 경로 조사 1.1
CONNECT 프록시에의 터널링 요구 1.1
LINK 리소스 간에 링크 관계를 확립 1.0
UNLINK 링크 관계 삭제 1.0
  • LINK가 UNLINK는 HTTP/1.1에서 폐기되어 제공하지 않는다.

지속 연결로 접속량을 절약

  • HTTP 초기 버전에는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었다.
  • 하나의 HTML에 여러 이미지가 포함되면서 리퀘스트를 보낼 떄마다 매번 TCP 연결과 종료를 하게 되며 통신량이 늘어나게 되었다.
  • HTTP/1.1과 일부 HTTP/1.0에서 TCP 연결 문제를 해결하기 위해 지속 연결이라는 방법을 고안했다.
  • 지속연결은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다. TCP 커넥션의 연결과 종료를 반복하는 오버헤드가 줄어들었기 때문에 서버에 대한 부하가 줄었다.
  • 지속 연결은 여러 리퀘스트를 보낼 수있도록 HTTP piplelining이 가능하게 되었다.
  • 파이프라인화에 의해서 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤 다음 리퀘스트를 발행하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있게 되었다.
  • 여러개의 리퀘스트를 보내야 되는경우 개별 연결보다는 지속연결이 빠르고, 지속 연결보다 파이프라인화 쪽이 빠르다.

쿠키를 상요한 상태 관리

  • HTTP는 stateless 프로토콜이다.
  • 상태가 없기떄문에, 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다는 장점이 있다. 그리고 상태가 없는 단순한 프로토콜이기에 HTTP가 다양한 곳에서 이용되는 측면도 있다.
  • HTTP가 stateless라는 특징을 남겨둔 채, 이 문제를 해결하기 위해 쿠키라는 시스템이 도입되었다.
  • 쿠키는 서버에서 response로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다. 다음 번에 클라이언트가 같은 서버로 request를 보낼 때, 자동으로 쿠키 값을 넣어서 송신한다. 서버는 클라이언트가 보내온 쿠키를 확인해 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.

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

HTTP 메시지

  • HTTP 메시지는 복수 행의 데이터로 구성된 텍스트 문자열이다.
  • HTTP 메시지는 크게 구분하면 메시지 헤더와 메시지 바디로 구분된다.
  • 메시지 헤더와 메시지 바디는 개행 문자(CL+LF)로 구분된다.

인코딩으로 전송 효율을 높이다

  • 메시지 바디와 엔티티 바디의 차이
    • 메시지: HTTP 통신의 기본 단위로 옥텟 시퀀스(8비트)로 구성되고 통신을 통해서 전송된다.
    • 엔티티: 리퀘스트랑 리스폰스의 페이로드(payload)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.
  • HTTP 메시지 바디의 역할은 리퀘스트랑 리스폰스에 관한 엔티티 바디를 운반하는 일이다.
  • 기본적으로 메시지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메시지 바디와 달라진다.
  • 압축해서 보내는 콘텐츠 코딩: HTTP에는 엔티티를 작게 압축해서 보내는 콘텐츠 코딩 기능이 구현되어 있다. 콘텐츠 압축에는 다음과 같은 것이 있다.
    • gzip(GNU zip)
    • compress(UNIX의 표준 압축)
    • deflate(zlib)
    • identity(인코딩 없음)
  • 분해해서 보내는 청크 전송 코딩: HTTP 통신에서는 리퀘스트 했던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않는다. 사이즈가 큰 데이터를 전송하는 경우 데이터를 분할해서 조금씩 표시할 수 있다. 이렇게 엔티티 바디를 분할하는 기능을 청크 전송 코딩이라고 부른다. 청크 사이즈르 16진수로 사용해서 단락을 표시하고 엔티티 바디 끝에는 “0(CR+LF)”를 기록한다.

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

  • HTTP에서 하나의 메시지 바디 내부에 엔티티를 여러개 포함시켜 보내는 멀티파트를 대응하고 있다. 주로 이미지나 텍스트 파일 등을 업로드할 때 사용된다.
  • 멀티파트에는 다음과 같은 것이 있다.
    • multipart/form-data: Web 폼으로부터 파일 업로드에 사용된다.
    • multipart/byteranges: 상태 코드 206(Partial content) 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용한다.
  • 멀티파트 각각의 엔티티를 구분하기 위해 “boundary” 문자열을 사용한다. 각 엔티티의 선두에는 “boundary” 문자열 앞에 “–“를 삽입한다. 멀티파트의 마지막에는 그 문자열의 마지막 부분에 “–“를 삽입한다.

일부분만 받는 레인지 리퀘스트

  • 예전에는 대용량의 이미지와 데이터를 다운로드할 때 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야했기 떄문에 힘들었다.
  • 이러한 문제를 해결하기 위해엔티티의 범위를 지정해서 다운로드 할 수 있도록 했다. 이를 레인지 리퀘스트(Range Request)라고 부른다.
  • 바이트 레인지는 다음과 같은 형식으로 지정할 수 있다.
    • 5001~10000 바이트 
      Range: bytes=5001-10000
    • 5001 바이트 이상 
      Range: bytes=5001-
    • 처음부터 3000 바이트까지, 그리고 5000~7000바이트까지의 복수 범위 
      Range: bytes=-3000, 5000-7000
  • 레인지 리퀘스트에 대한 리스폰스는 상태 코드 206 Partial Content 라는 리스폰스 메시지가 되돌아온다. 또한, 복수 범위의 레인지 리퀘스트에 대한 리스폰스는 multipart/byteranges로 리스폰스가 되돌아온다.
  • 서버가 레인지 리퀘스트에 지원하지 않는 경우에는 상태 코드 200 OK라는 리스폰스 메시지로 완전한 엔티티가 되돌아온다.

최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

  • 클라이언트와 서버가 제공하는 리소스의 내용에 대해 교섭하는 것을 콘텐츠 네고시에이션이라고 한다. 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조다.
  • 콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단한다.
    • Accept
    • Accept-Charset
    • Accept-Encoding
    • Accept-Launguage
    • Content-Launguage
  • 콘텐츠 네고시에이션에는 다음과 같은 종류들이 있다.
    • 서버 구동형 네고시에이션: 서버 측에서 콘텐츠 네고시에이션을 하는 방식이다. 서버측에서 리퀘스트 필드의 정보를 참고해서 자동적으로 처리한다. 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 정말로 적절한 것이 선택되었다고 할 수 없다.
    • 에이전트 구동형 네고시에이션: 클라이언트 측에서 콘튼체 네고시에이션을 하는 방식이다. 브라우저에 표시된 선택지 중에 유저가 수동으로 선택한다. 일반적으로 JavaScript 등을 사용해서 웹 페이지에서 자동적으로 이것을 정한다.
    • 트랜스페어런트 네고시에이션: 서버 구동형과 에이전트 구동형을 혼합한 것으로 서버와 클라이언트가 각각 컨텐츠 네고시에이션을 한다.

결과를 전달하는 HTTP 상태 코드

상태 코드는 서버로부터 리퀘스트 결과를 전달한다.

  • 클라이언트가 서버를 향해 리퀘스트를 보낼 떄 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다.

  • 상태 코드의 클래스

      클래스 설명
    1xx Informational 리퀘스트를 받아들여 처리중
    2xx Success 리퀘스트를 정상적으로 처리했음
    3xx Redirection 리퀘스트를 완료하기 위해서 추가 동작이 필요
    4xx Client Error 서버는 리퀘스트 이해 불가능
    5xx Server Error 서버는 리퀘스트 처리 실패
  • 클래스의 정의만 지킨다면 RFC2616에 정의된 상태 코드를 변경하거나 서버 독자적인 상태 코드를 만들어도 상관없다.

2xx 성공(Success)

  • 200 OK: 클라이언트가 보낸 리퀘스트를 서버가 정상 처리하였음을 나타낸다. 리스폰스에서 상태 코드와 함께 되돌아 오는 정보는 메소드에 따라 다르다. GET 메소드의 경우에는 리퀘스트된 리소스에 대응하는 엔티티가 리스폰스로 보내지고 HEAD 메소드의 경우에는 리퀘스트된 리소스에 대응하는 엔티티 헤더 필드가 메시지 바디를 동반하지 않고 리스폰스로 되돌아온다.
  • 204 No Content: 서버 리퀘스트를 받아서 처리하는데 성공했지만 리스폰스에 엔티티 바디를 포함하지 않는다. 클라이언트에서 서버에 정보를 보내는 것으로 족하고, 클라이언트에 대해서 새로운 정보를 보낼 필요가 없는 경우에 사용된다.
  • 206 Partial Content: Range에 의해서 범위가 지정된 리퀘스트에 의해서 서버가 부분적 GET 리퀘스트를 받았음을 나타내고 있다. 리스폰스에는 Content-Range로 지정된 범위의 엔티티가 퐇마되게 된다.

3xx 리다이렉터(Redirection)

  • 301 Moved Permanently: 리퀘스트된 리소스에는 새로운 URI로 영구히 이동되었기 떄문에 이후로는 그 리소를 참조하는 URi를 사용해야된다는 뜻이다. 새로운 URI는 L Location 헤더 필드에 명시되어 있다.
  • 302 Found: 리퀘스트된 리소스가 새로운 URI로 일시적으로 이동했다는 뜻이다.
  • 303 See Other: 리퀘스트에 대한 리소스가 다른 URI에 있기 떄문에 GET 메소드를 사요해서 얻어야 한다는 것을 나타낸다. 302 Found와 같은 기능이지만, 리다이렉트 장소를 GET 메소드로 얻어야 한다고 명확하게 되어 있는 점이 302와 다르다.
  • 304 Not Modified: 클라이언트가 조건부 리퀘스를 했을 때 리소스에 대한 접근은 허락하지만, 조건이 충족되지 않음을 표시하고 있다. 304를 되돌려 줄 경우에는 리스폰스 바디에 어떤 것도 포함되어 있어서는 안된다.
  • 307 Temporary Redirect: 302 Found와 의미가 같지만, 302의 경우에는 POST로부터 GET으로 치환이 금지되어 있는데도 불구하고 구현상 그와 같이 되어 있지는 않다. 307에서는브라우저 사양에 따라 POST에서 GET으로 치환을 하지 않는다.
  • 301, 302, 303 리스폰스 코드가 되돌아 오면, 대부분의 브라우저에서는 POST를 GET으로 바꾸어서 리퀘스트의 엔티티 바디를 삭제하고 레퀘스트를 자동적으로 재송신하도록 되어있다. 301, 302의 사양은 POST 메소드를 GET 메소드에 바꾸는 것을 금지하고 있지만 구현해 놓은 것을 보면 이렇게 되어 있는 것이 대부분이다.

4xx 클라이언트 에러(Client Error)

  • 400 Bad Request: 리퀘스트 구문이 잘못되었음을 나타내고 있다. 이 에러가 발생한 경우, 리퀘스트 내용을 재검토하고 나서 재송신할 필요가 있다.
  • 401 Unauthorized: 리퀘스트에 HTTP 인증(BASIC 인증, DIGEST 인증)정보가 필요하다는 것을 나타낸다. 또한, 이미 1번 리퀘스트가 이루어진 경우에는 유저 인증에 실패했음을 표시한다. 401을 포함한 리스폰스를 되돌리느 경우에는 리퀘스트 된 리소스에 적용되는 challenge를 포함한 WWW-Authenticate 헤더 필드를 포함할 필요가 있다.
  • 403 Forbidden: 리퀙스트된 리소스의 엑세스가 거부되었음을 나타낸다. 403이 발생한 원인으로는 파일 시스템의 퍼미션이 부여되지 않은 경우와 액세스 권한에 문제(허가되지 않은 송신 IP 주소의 액세스 등)가 있는 것을 예로 들 수 있다.
  • 404 Not Found: 리퀘스트한 리소스가 서버상에 없다는 것을 나타낸다. 그 외에도서버 측에 해당 리퀘스트를 거부하고 싶은 이유를 분명히 하고싶ㅇ지 않은 경우에도 이용할 수 있다.

5xx 서버 에러(Server Error)

  • 500 Internal Server Error: 서버에서 리퀘스트를 처리하는 도중에 에러가 발생하였음을 나타낸다. 웹 애플리케이션에 에러가 발생한 경우나 일시적인 경우도 있다.
  • 503 Service Unavaliable: 서버가 과부하 상태이거나 점검중이기 떄문에 현재 리퀘스트를 처리할 수 없음을 나타낸다. 이 상태가 해소되기까지 시간이 걸리는 경우에느 Retry-After 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직하다.

HTTP와 연계하는 웹 서버

1대로 멀티 도메인을 가능하게 하는 가상 호스트

  • 가상 호스트 기능을 사용하면 물리적으로 서버가1대지만 가상으로 여러 대가 있는 것처럼 설정하는 것이 가능하다.
  • 인터넷에서 도메인명은 NDS에 의해서 IP 주소로 변환되고 나서 엑세스하게 된다. 결국 리퀘스트가 서버에 도착한 시점에는 IP 주소를 기준으로 엑세스하게 된다.
  • 같은 IP주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있는 가상 호스트의 시스템이 있기 때문에, HTTP 리퀘스트를 보내는 경우에는 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 된다.

통신을 중계하는 프로그램: 프록시, 게이트웨이, 터널

  • 프록시: 클라이언트로부터 받은 HTTP 리퀘스트를 다른 서버에 전송한다. 리소스 본체를 가진 서버를 오리진 서버라고 부른다. 프록시 서버를 사용하는 이유는 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용하는 것과 조직 내에 특정 웹사이트에 대한 엑세스 제한, 엑세스 로그를 획득하는 정책을 철저하게 지키려는 목적으로 사용하는 경우가 있다.
    • 캐싱 프록시: 프록시 서버 상에 리소스 캐시를 보존해 두는 타입
    • 투명 프록시: 프록시로 리퀘스트와 리스폰스를 중계를 할 때 메시지 변경을 하지 않는 타입
  • 게이트웨이: HTTP 리퀘스트에 의해 다른 프로토콜의 서버 서비스를 제공하는 하게 해준다. 또한 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전하게 접속함으로써 통신의 안정성을 높이는 역할도 있다.
  • 터널: 서로 떨어진 클라이언트와 사이를 중계하여 접속을 주선하는 중계 프로그램이다. 터널 자체는 HTTP 리퀘스트를 해석하려고 하지 않는다. 결국 리퀘스트를 그대로 다음 서버에 중계한다. 그리고 터널은 통신하고 있는 양쪽 끝의 접속이 끊어질 때에 종료한다.

리소스를 보관하는 캐시

  • 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다. 캐시를 사용하면리소스를 가진 서버에서의 엑세스를 줄이는 것이 가능하기 때문에 통신량과 통신 시간을 절약할 수 있다.
  • 캐시를 가지고 있더라도 클라이언트의 요구나 캐시의 유효 기간 등에 의해서 오리진 서버에 리소스의 유효성을 확인하거나 새로운 리소스를 다시 획득하러 가게 되는 경우가 있다.

HTTP 헤더

HTTP 메시지 헤더

  • 리퀘스트 HTTP 메시지의 메시지 헤더
    • 리퀘스트 라인: 메서드, URI, HTTP 버전
    • 리퀘스트 헤더 필드
    • 일반 헤더 필드
    • 엔티티 헤더 필드
    • 그 외
  • 리스폰스 HTTP 메시지의 메시지 헤더
    • 상태 라인: HTTP 버전, 상태 코드
    • 리스폰스 헤더 필드
    • 일반 헤더 필드
    • 엔티티 헤더 필드
    • 그 외

HTTP 헤더 필드

  • HTTP 헤더 필드는 부가적으로 중요한 정보를 전달하는 역할을 담당한다.
  • HTTP 헤더 필드는 헤더 필드 명과 필드 값으로 구성되어 있고 콜론”:”으로 나뉘어져 있다.
  • HTTP 메시지 헤더 중에 같은 헤더 필드 명이 두개 이상 있따면 브라우저 마다 다르게 처리되기 떄문에 조심해야된다.
  • HTTP 헤더 필드의 4종류
    • 일반적 헤더 필드(General Header Fields): 리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더
    • 리퀘스트 헤더 필드(Request Header Fields): 리퀘스트 메시지에 사용되는 헤더로 리퀘스트의 부가적 정보와 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등을 부가한다.
    • 리스폰스 헤더 필드(Response Header Fields): 리스폰스 메시지에 사용되는 헤더로 리스폰스의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가한다.
    • 엔티티 헤더 필드(Entity Header Fields): 에닡티에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.
  • 헤더 필드는 47 종류가 있다.
  • Set-Cookie, Content-Disposition과 같은 비표준 헤더 필드도 있다.
  • 캐시와 비캐시 프록시의 동작을 정의하기 위해서 두가지 HTTP 헤더 필드의 종류가 있다.
    • End-to-end 헤더: 리퀘스트나 리스폰스가 최종 수신자에게 전송되야 하는 헤더다. 프록시는 이 헤더를 수정하지 않은 상태로 재전송해야되며, 캐시에 이를 저장해야된다.
    • Hop-by-hop 헤더: 한 번 전송에 대해서만 유효하고 캐시나 프록시에 의해서 재전송되지 않는다. HTTP/1.1과 그 이후에는 사용되는 Hop-by-hop 헤더는 Connection 헤더 필드에 열거해야한다.
    • 아래에 열거하는 8개의 헤더 필드 외에는 모두 End-by-end 헤더로 분류된다.
      • Connection
      • Keep-Alive
      • Proxy-Authenticate
      • Proxy-Authorization
      • Trailer
      • TE
      • Transfer-Encoding
      • Upgrade

HTTP/1.1 일반 헤더 필드

  • Cache-Control: 디렉티브로 불리는 명령을 사용하여 캐싱 동작을 지정한다.
    • 캐시가 가능한지 여부를 나타내는 디렉티브
      • public: 리스폰스에 있는 경우, 다른 유저에게도 돌려줄 수 있는 캐시를 해도 좋다는 것이다.
      • private: 리스폰스에 있는 경우, 특정 유저만을 대상으로 하고 있다는 것을 나타낸다.
      • no-cache: 리퀘스트에 있는 경우, 캐시된 리스폰스를 클라이언트가 받아들이지 않음을 나타낸다. 즉, 중간 캐시 서버가 오리진 서버까지 리퀘스트를 전송한다. 리스폰스에 있는 경우, 캐시 서버는 리소스를 저장할 수 없다. 정확히는 캐시는 하되 캐시가 유효한지 오리진 서버에 매번 확인한다. 
        Cache-Control: no-cache=Location

        리스폰스로 no-cache의 헤더 값이 헤더 필드 명이 지정된 경우에는 이 지정된 헤더 필드만 캐시할 수 없도록 한다.

    • 캐시로 보존 가능한 것을 제어하는 디렉티브
      • no-store: 리퀘스트 혹은 리스폰스에 기밀 정보가 포함되어 있음을 나타낸다. 캐시 서버에 어떠한 부부도 캐시되지 않는다.
    • 캐시 기한이나 검증을 지정하는 디렉티브
      • s-maxage: max-age 디렉티브와 동일한테 다른 점은 여러 유저가 이용할 수 있는 공유 캐시 서버에만 적용된다는 점이다. 또한 s-maxage 디렉티브가 사용되는 경우, Expires 헤더 필드와 max-age 디렉티브는 무시된다.
      • max-age: 리퀘스트에 있는 경우, 지정되있는 값보다 새로운 경우에는 캐시되었던 리소스를 받아들일 수 있다. 리스폰스에 있는 경우, 캐시 서버가 유효성을 재확인 하지 않고 리소스를 캐시에 보존해 두는 최대 시간을 나타낸다. HTTP/1.1 캐시 서버는 동시에 Expires 헤더 필드가 있는 경우에는 max-age 디렉티브 지정을 우선하고 Expires 헤더 필드를 무시한다. HTTP/1.0 캐시 서버는 반대로 max-age 디렉티브가 무시된다.
      • min-fresh: 캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반화하도록 캐시 서버에 요구한다. 예를들면, 60초로 지정되어 있는 경우에는 60초 이내에 유효 기간이 끝나는 리소스를 리스폰스로 반환하면 안된다.
      • max-stale: 리퀘스트에 있는 경우, 캐시된 리소스의 유효 기간이 끝났더라도 받아들일 수 있음을 나타낸다. 디렉티브에 값이 지정되어 있지 않는 경우에는 클라이언트는 아무리 시간이 경과했더라도 리스폰스를 받아들인다. 값이 지정되어 있는 경우에는 유효 기한이 지난 후로부터 지정 시간 내라면 받아 들인다는 뜻을 서버에 전달한다.
      • only-if-cached: 리퀘스트에 있는 경우, 클라이언트는 캐시 서버에 대해서 목적한 리소스가 로컬 캐시에 있는 경우만 리스폰스를 반환하도록 요구한다. 즉, 캐시 서버에서 리스폰스의 리로드와 유효성을 재확인하지 않도록 요구한다. 캐시 서버가 로컬 캐시로부터 응답할 수 없는 경우에는 “504 Gateway Timeout” 상태를 반환한다.
      • must-revalidate: 리스폰스의 캐시가 현재도 유효한지 아닌지의 여부를 오리진 서버에 조회를 요구한다. 프록시가 오리진 서버에 도달할 수 없고, 리소스를 다시 요구할 수 없는 경우에는 캐시는 클라이언트에 504 Gateway Timeout을 반환한다. 또한, must-revalidate가 사요오디는 경우, 리퀘스트에서 max-stale 디렉티브를 사용하고 있더라도 무시한다.
      • proxy-revalidate: 모든 캐시 서버에 대해서 이후의 리퀘스트로 해당 리스폰스를 반환할 때는 반드시 유효성 재확인을 하도록 요구한다.
      • no-transform: 리퀘스트와 리스폰스의 어느 쪽에 있어도 캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정한다. 이렇게 해서 캐시 서버 등에 의해서 이미지가 압축되는 것을 방지한다.
    • Cache-Control 확장
      • cache-extension 토큰: cache-extension 토큰을 사용하여 디렉티브를 확장할 수 있다. community라는 디렉티브는 extension token에 의해서 추가할 수 있다.
  • Connection
    • 프록시에 더 이상 전송하지 않는 헤더 필드를 지정하거나 지속적인 접속 관리를 하는 역할을 한다.
    • 전송하지 않는 헤더 필드 지정: Connection: Upgrade라고 리퀘스트를 보내면 프록시 서버부터는 Upgrade 필드가 사라진다.
    • 지속적인 접속 관리: HTTP/1.1에서는 지속적 접속이 디폴트로 되어 있다. 그래서 리퀘스트를 송신했던 클라이언트는 접속이 계속 유지되면서 추가 리퀘스트를 송신하도록 한다. 이 떄 서버측에서 명시적으로 접속을 끊고 싶은 경우에는 Connection: Close 헤더를 추가한다. HTTP/1.1 이전 버전의 HTTP에서는 지속적 접속이 디폴트가 아니었다 그렇기 때문에 지속적 접속을 하고싶은 경우에는 Connection: Keep-Alive라고 지정해야된다.
  • Date: HTTP 메시지를 생성한 날짜를 나타낸다.
  • Pragma: HTTP/1.1 보다 오래된 버전의 흔적이다. 중간 서버의 HTTP 버전을 모두 파악한 후에 리퀘스트를 보내는 일은 현실적으로 없기떄문에 캐시된 리스폰스를 원친 않을때는 아래와 같이 보낸다. 
    Cache-Control: no-cache
Pragma: no-cache
  • Trailer: 헤더 필드가 메시지 바디의 뒤에 기술되어 있는 경우 미리 전달할 수 있다.
  • Transfer-Encoding: 메시지 바디의 전송 코딩 형식을 지정하는 경우에 사용된다.
  • Upgrade: HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용된다. 전혀 다른 통신 프로토콜이라고 하더라도 문제가 없다. 대표적인 예로 TLS/1.0이 있다. Upgrade 헤더 필드는 인접한 서버 사이기 때문에, Connection:Upgrade도 지정할 필요가 있다. Upgrade 헤더 필드가 달린 리퀘스트에 대해서는 서버는 상태 코드 101 Switching Protocols 이라는 리스폰스로 응답할 수 있다.
  • Via: 클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 우해서 사용된다. 전송된 메시지의 추적과 리퀘스트 루프의 회피 등에 사용되기 때문에 프록시를 경유하는 경우에는 반드시 부가할 필요가 있다.
  • Warning: HTTP/1.0 리스폰스 헤더(Retry-After)가 HTTP/1.1에서 변경된 것으로, 리스폰스에 경고를 유저에게 전달한다 Warning 헤더 형식은 다음과 같다. 
    Warning: [경고 코드][경고한 호스트:포트 번호]"[경고문]" ([날짜])

리퀘스트 헤더 필드

  • Accept: 유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선 쉰위를 전달하기 위해서 사용한다. 표시하는 미디어 타입에 우선 순위를 붙이고 싶은 경우에는 “;”으로 구분하고 “q=”로 표시할 품질 지수를 더한다. 
    Accept: text/html, application/xhtml+xml,application/xml;q-0.9,*/*;q=0.8
    • 텍스트 파일: text/html, text/plain, text/css, application/xhtml+xml, application/ xml, …
    • 이미지 파일: image/jpeg, image/gif, image/png, …
    • 동영상 파일: video/mpeg, video/quicktime, …
    • 애플리케이션용 바이너리 파일: application/octet-stream, application/zip, …
  • Accept-Charset: 유저 에이전트에서 처리할 수 있는 문자셋으로, 문자셋의 상대적인 우선 순위를 전달하기 위해 사용된다.
  • Accept-Encoding: 유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 콤텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용된다. “*“를 지정하면 와일드 카드로서 모든 인코딩 포맷을 가리킨다.
    • gzip
    • compress
    • deflate
    • identity
  • Accept-Language: 유저 에이전트가 처리할 수 있는 자연어 세트와 자연어 세트의 상대적인 우선 순위를 전달하기 위해서 사용된다.
  • Authorization: 유저 에이전트의 인증 정보를 전달하기 위해서 사용된다. 공유 캐시가 Authorization 헤더 필드를 포함하는 리퀘스틑를 받은 경우는 조금 다르게 동작한다.
  • Expect: 클라이언트가 서버에 특정 동작 요구를 전달한다. 기대하고 있는 요구에 서버가 응답하지 못해서 에러가 발생하는 경우엔느 상태코드 417 Expectation Failed를 반환한다. HTTP/1.1 사양에서는 “100-continue”만 정의되어있다.
  • From: 유저 에이전트를 사용하고 있는 유저의 메일 주소를 전달한다.
  • Host: 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다. Host 헤더 필드가 존재하는 이유는 1대의 서버에 복수의 도메인을 할당할 수 있는 가상 호스트의 구조와 관련있다. 서버에 호스트 명이 설저오디어 있지 않는 경우에는 아래와 같이 값을 비워서 보낸다.
  • If-Match: 조건부 리퀘스트를 받은 서버는 지정된 조건에 맞는 경우에만 리퀘스트를 받는다. If-Match 헤더 필드는 조건부 리퀘스트의 하나로 서버 상의 리소스를 특정하기 위해서 엔티티 태그(ETag) 값을 전달한다. “*“를 지정할 수도 있다.
  • If-Modified-Since: 조건부 리퀘스트의 하나로 리소스가 갱신 날짜가 필드 값보다 새롭다면 리퀘스트를 받아들이겠다는 뜻을 전달한다. 지정한 리소스가 갱신되어 있지 않은 경우에는 상태 코드 304 Not Modified 리스폰스를 반환한다.
  • If-None-Match: 필드 값에 지정된 엔티티 태그(ETag) 값이 지정된 리소스의 ETag 값과 일치하지 않으면 리퀘스트를 받아들이겠다는 뜻을 전달한다. GET과 HEAD 메소드에 IF-None-Match 헤더 필드를 사용함으로써 최신의 리소스를 요구하는 것이 되기 때문에 If-Modified-Since 헤더 필드를 사용하는 것과 비슷하다.
  • If-Range: 조건부 리퀘스트의 하나로 If-Range로 지정한 필드값(ETag 값)과 지정한 리소스의 ETag 값 혹은 날짜가 일치하면 Range 리퀘스트로서 처리하고 싶다는 것을 전달한다. 일치하지 않는 경우에는 리소스 전체를 반환한다.
  • If-Unmodified-Since: 지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되어 있지 않는 경우에만 리퀘스트를 받아들이도록 전달한다. 지정된 날짜 이후에 갱신된 경우에는 412 Precondition Failed 리스폰스를 반환한다.
  • Max-Forwards: TRACE 혹은 OPTIONS 메소드에 의한 리퀘스트를 할 때에 전송해도 좋은 서버의 수의 초대치를 10진수 정수로 지정한다. 서버는 다음 서버에 리퀘스트를 전송할 때 Max-Forwards 값에서 1을 빼서 다시 세트한다. Max-Forwards 값이 0인 리퀘스트를 받은 경우에는 전송하지 않고 리스폰스를 반환한다. HTTP를 사용한 통신 도중에 프록시 서버에 무언가의 원인으로 리퀘스트 전송이 실패하게 되면 클라이언트에는 리스폰스가 되돌아 오지 않기때문에 이 필드가 필요하다.
  • Proxy-Authorization: 프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트의 정보를 전달한다.
  • Range: 리소스의 일부분만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다. 서버가 리퀘스트를 처리할 경우에는 상태 코드 206 Partial Content 리스폰스를 반환한다. Range 리퀘스트를 처리할 수 없는 경우에는 상태 코드 200 OK 리스폰스로 리소스 전체를 반환한다.
  • Referer: 리퀘스트가 발생한 본래 리소스의 URI를 전달한다. 기본적으로 Referer 헤더 필드는 보내져야 하지만, 브라우저의 주소창에 직접 URI를 입력한 경우와 보안상 바람직하지 않다고 판단된 경우에는 보내지 않아도 괜찮다.
  • TE: 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위를 전달한다. 전송 코딩의 지정 이외에 Trailer를 동반하는 청크 전송 인코딩 형식을 지정하는 것이 가능하다. 이 경우, 필드 값에 “trailers”라고 기록한다.
  • User-Agent: 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드다.

리스폰스 헤더 필드

  • Accept-Ranges: 서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 전달한다. 지정 가능한 필드 값은 2개이면 수신한 경우에는 “bytes”, 수신 불가능한 경우에는 “none”이라고 기록한다.
  • Age: 얼마나 오랜 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달한다.
  • ETag: 엔티티 태그라고 불리며 일의적으로 리소스를 특정하기 위한 문자열을 전달한다. 리소스가 갱신되면 ETag 값도 갱신할 필요가 있다.
    • 강한 ETag 값: 엔티티가 아주 조금 다르더라도 반드시 값이 변한다.
    • 약한 ETag 값: 의미가 다른 리소스로 그 차이가 있는 경우에만 ETag 값이 변한다. 또한, 값의 앞부분에 “W/”가 붙는다.
  • Location: 리다이렉트 처의 URI을 기술하는데 사용된다.
  • Proxy-Authenticate: 프로시 서버에서의 인증 요구를 클라이언트에 전달한다.
  • Retry-After: 클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지를 전달한다. 주로 상태 코드 503 Service Unavailable 리스폰스나 3xx Redirect 리스폰스와 함께 사용된다. 값으로는 날짜나 리스폰스 이후의 몇 초를 지정할 수 있다.
  • Server: 서버에 설치되어 있는 HHTP 서버의 소프트웨어를 전달한다.
  • Vary: 캐시를 컨트롤하기 위해서 사용한다. 오리진 서버로부터 Vary에 지정되었던 헤더 필드를 가진 리퀘스트에 대해서만 캐시를 반환할 수 있다.
  • WWW-Authenticate: HTTP 엑세스 인증에 사용되는데 Request-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마(“Basic”, “Digest” 등)와 파라미터를 나타내는 challenge를 전달한다. WWW-Authenticate 헤더 필드는 상태 코드 401 Unauthorized 리스폰스에 반드시 포함된다. 아래 예에서 “realm”는 Request-URI에 지정된 보호되었던 리소스를 식별하기 위한 문자열이다. 
    WWW-Authenticate: Basic realm="Usagidesign Auth"

엔티티 헤더 필드

  • Allow: Request-URI에 지정된 리소스가 제공하는 메소드의 일람을 전달한다. 서버가 받을 수 없는 메소드를 수신한 경우에는 상태 코드 405 Method Not Allowed 리스폰스와 함꼐 수신 가능한 메소드의 일람을 기술한 Allow 헤더 필드를 반환한다.
  • Content-Encoding: 서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달한다.
    • Gzip
    • Compress
    • Deflate
    • Identity
  • Content-Language: 엔티티 바디에 사용된 자연어를 전달한다.
  • Content-Length: 엔티티 바디의 크기(단위는 bytes)를 전달한다. 엔티티 바디에 전송 코딩이 실시된 겨우에는 Content-Length 헤더 필드는 사용해서는 안된다.
  • Content-Location: 메시지 바디에 대응하는 URI를 전달한다. Location 헤더 필드와 달리 메시지 바디로 반환된 리소스 URI를 나타낸다. 예를들어, Accept-Language 헤더 필드를 사용한 서버 구동형 리퀘스트는 실제로 요구된 오브젝트와 다른 페이지가 반환 되었을때 Content-Location 헤더 필드에 URI를 포함한다.
  • Content-MD5: 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달한다. HTTP 헤더에는 바이너리 값을 기록하는 것이 불가능하기 때문에 Base64로 인코딩하고 있다. 우발적으로 콘텐츠가 변경되어 버린 사실을 알 수 있지만 악의를 가진 변조는 검출할 수 없다. 컴텐츠를 변조하면 Content-MD5도 재계산해서 변조하는 것이 가능하기 때문이다.
  • Content-Range: 범위를 지정해서 일부분만 리퀘스트하는 Range 리퀘스트에 대해서 리스폰스 할 때에 사용된다. 리스폰스로 보낸 엔티티가 어느 부분에 해당하는가를 전달한다.
  • Content-Type: 엔티티 바디에 퐇마되는 오브젝트의 미디어 타입을 전달한다.
  • Expires: 리소스의 유효 기한 날짜를 전달한다. 오리진 서버가 캐시 서버에 캐시되는 것을 원하지 않을 경우에는 Date 헤더 필드 값과 같은 날짜로 해두는 것이 바람직하다. Cache-Control 헤더 필드에 max-age 디렉티브가 지정되어 있는 경우에는 Expires 헤더 필드보다 max-age 디렉티브의 지정이 우선된다.
  • Last-Modified: 리소스가 마지막으로 갱신되었던 날짜 정보를 전달한다. 기본적으로 Request-URI가 지정된 리소스가 갱신된 날짜가 되지만, CGI 등의 스크립트로 동적인 데이터를 다룰 경우에는 그 데이터의 최종 갱신 날짜가 되는 경우도 있다.

쿠키를 위한 헤더 필드

  • 쿠키는 HTTP/1.1의 사양인 RFC2616에 포함되는 것은 아니지만 웹 사이트에 널리 사용되고 있다. 쿠키는 유저 식별과 상태 관리에 사용되고 있는 기능이다.
  • 쿠키의 사양서는 2013년 5월 기준으로 알와 같이 4종류가 있다.
    • 넷스케이프사에 의한 사양: 1994년 경에 넷스케이프 브라우저에 기능이 추가되었다.
    • RFC2109: 한 기업의 독자적인 기술이었던 쿠키사양의 표준화를 시허해 보기 위해서 정리된 규격이다. 지금은 사용되지 않느다.
    • RFC2965: 인터넷 익스플로러와 넷스케이프 내비게이터의 서로다른 규격 때문에 새롭게 “Set-Cookie2”와 “Cookie2”라는 HTTP 헤더 필드를 정의했지만 실제로는 거의 사용되지 않는다.
    • RFC6265: 넷스케이프사에 의한 사양을 디펙토 스탠다드로서 쿠키의 사양을 재정의 한것이다.
  • Set-Cookie: 서버가 클라이언트에 대해서상태 관리를 시작할 때 다양한 정보를 전달한다. 필드 값은 다음과 같은 정보가 있다.
    • NAME=VALUE: 쿠키에 부여된 이름과 값(필수)
    • Expires=DATE: 쿠키 유효 기간(지정되지 않은 경우는 브라우저를 닫을 때까지)
    • Path=PATH: 쿠키 저굥 대상이 되는 서버상의 디렉토리(지정하지 않은 경우는 도큐먼트와 같은 디렉토리)
    • Domain=도메인 명: 쿠키 적용 대상이 되는 도메인 명(지정하지 않은 경우는 쿠키를 생성한 서버의 도메인). 명시적으로 여러 도메인에 대해서 쿠키를 송출하는 경우에를 제외하고는 domian 속성을 지정하지 않는 쪽이 안전하다.
    • Secure: HTTPS로 통신하고 있는 경우에만 쿠키를 송신
    • HttpOnly: 쿠키를 JavaScript에서 액세서하지 못하도록 제한. 크로스 사이트 스크립팅(XSS)으로부터 쿠키의 도청을 막는 것을 목적으로 하고있다. 하지만 XSS 자체를 막는 것은 아니다.
  • Cookie: 클라이언트가 HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키의 이후의 리퀘스트에 포함해서 전달한다. 쿠키를 여러개 수신하고 있을 때는에는 쿠키를 여러개 보내는 것도 가능하다.

그 이외의 헤더 필드

  • X-Frame-Option: 다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP 리스폰스 헤더로, 클릭 재킨(click jacking)이라는 공격을 막는 것을 목적으로 하고 있다. 필드에 지정할 수 있는 값은 아래와 같다. X-Frame-Option은 대부분의 브라우저에서 지원하고 모든 웹 서버에서 설정해두는 것이 바람직하다.
    • DENY: 거부
    • SAMEORIGIN: Top-level-browsing-context가 일치한 경우에만 허가.
  • X-XSS-Protection: 크로스 사이트 스크립팅 대책으로서 브라우저의 XSS 보호 기능을 제어하는 HTTP 리스폰스 헤더다. X-XSS-Protection 헤더 필드에 지정할 수 있는 값은 아래와 같은 것이 있다.
    • 0: XSS 필터를 무효로 한다.
    • 1: XSS 필터를 유효로 한다.
  • DNT: Do Not Track이라는 뜻이며 개인 정보 수집을 거부하는 의사를 나타내는 HTTP 리퀘스트 헤더다. DNT 헤더 필드는 아래와 같은 값을 지정할 수 있다. DNT 헤더 필드의 기능이 유효성을 유지하기 위해서는 웹 서버에서 DNT를 지원해야 할 필요가 있다.
    • 0: 트래킹 동의
    • 1: 트래킹 거부
  • P3P: 웹 사이트 상의 프라이버시 정책에 P3P(The Platform for Privacy Preferences)를 사용하는 것으로, 프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP 리스폰스 헤더다.
  • HTTP를 시작으로 많은 프로토콜에서는 비표준 파라미터에 “X-“ 접두사를 붙이는 것으로, 표준 파라미터와 비표준 파라미터를 부려했다. 하지만 이 방법은 장점은 없고 단점만 많아서 그만두기로 한 것이 제안되었다. 다만, 이미 구현된 “X-“ 접두사의 변경을 요구하는 것은 아니다.

웹을 안전하게 지켜주는 HTTPS

HTTP의 약점

  • HTTP는 주로 다음과 같은 약점을 가지고 있다.
    • 평문이기 때문에 도청 가능: 어느 서버와 클라이언트가 통신을 할 때, 통신 경로 상에 잇는 네트워크 기기나 케이블 등을 전부 자기 자신이 소유하고 있는 일은 있을 수 없다. 따라서 악의를 가진 누군가가 엿볼 수 있다. 도청으로부터 정보를 지키키 위해서 주로 암호화를 사용한다. 1. 통신 암호화는 HTTP에는 암호화 구조가 없지만 SSL이나 TLS이라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. 2. 콘텐츠 암호화는 콘텐츠의 내용 자체를 암호화해 버리는 방법이다. 이 방법은 서버가 콘텐츠의 암호화나 복호화 구조를 가지고 있는 전제가 되므로, 평상시에 유저가 사용하는 브라우저와 웹 서버에서는 이용하는 것이 어렵다. 주로 웹 서비스 등에서 이용되는 방법이다.
    • 통신 상대를 확인하지 않기 때문에 위장 가능: HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 떄문에 누구든지 리퀘스트를 보낼 수 있다. 따라서, 클라이언트 또는 웹서버가 위장할 수도 있고, 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다. 또한 의미없는 리퀘스트라도 수신할 수 있어서 대량의 리퀘스트에 의한 DoS 공격을 방지할 수가 없다. 이를 해결하기 위해 SSL을 사용한다. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고있다. 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 또한 이 증명서는 위조하는 것이 기술적으로 상당히 어렵다.
    • 완전성을 증명할 수 없기 때문에 변조 가능: 공격자가 도중에 리퀘스트나 리스폰스를 뺴앗아 변조하는 중간자 공격을 막을 수 없다. HTTP로 완정성을 확인하기 위해서는 MD5나 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명(PGP)을 확인하는 방법이 있는데 이는 확실하지는 않다. PGP와 MD5 자체도 적절하게 수정되어 있다면, 유저로서는 알 수가 없다. 확실히 방지하기 위해서는 HTTPs를 사용할 필요가 있다. SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS

  • HTTP에 암호화나 인증 등의 구조를 더한것을 HTTPS(HTTP Secure)라고 부른다.
  • HTTPS는 새로운 프로토콜이 아니라 HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)나 TLS(Transport Layer Security)라는 프로토콜로 대체하고 있는 것이다.
  • HTTP는 보통 TCP와 직접 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL와 통신하고 SSL이 TCP와 통신하게 된다.
  • SSL은 공통키 암호화 방식을 채용하고 있다. 하지만 공통키 암호화 방식은 상대방에게 키를 넘겨줄 때 문제가 된다.
  • 공통키 암호의 문제를 해결하려고 한 것이 공개키 암호방식이다. 공개키 방식은 큰 수의 소인수 분해를 고속으로 할 수 있다면 해독할 수 있지만, 현재로선 쉽지 않다.
  • 공개키 암호는 공통키 암호에 비해서 처리 속도가 느리다. 따라서 HTTPS는 두 가지 방식을 조합해서 통신한다. 공통키를 교환할 때는 공개키 암호를 사용하고 그 후의 통신에서 메시지를 교환할 때는 공통키를 사용한다.
  • 하지만 공개키도 공격자가 공개키를 바꿔치기 할 수 있기때문에 공개키가 진짜인지 증명할 방법이 필요하다. 이 문제를 해결하는 데는 인증 기관과 그 기관이 발행하는 공개키 증명서가 이용된다. 유명한 인증 기관에는 VeriSign사가 있다.
  • 인증 과정은 다음과 같다.
    1. 서버 운영자가 인증 기관에 공개키를 제출한다.
    2. 인증기관은 인증 기관의 비밀키로 제출된 공개키에 디지털 서명을한 공개키 인증서를 등록한다.
    3. 클라이언트는 서버의 공개키 증명서를 입수하고, 디지털 서명을 인증 기관의 공개 키로 검증하고, 진짜 공개키인지 확인한다.
    4. 클라이언트는 공동키를 서버의 공개키로 암호화해서 서버에 보낸다.
    5. 서버는 받은 메시지를 서버의 비밀키로 복호화한다.
  • 증명서는 서버가 올바른 통신 상대임을 증명하는 역할을하지만, 상대방이 실제로 있는 기업인지를 확인하는 역할도 한다. 그런 역할을 가진 증명서를 EV SSL 증명서라고 한다.
  • HTTPS에는 클라이언트 증명서도 이용할 수 있다. 하지만 클라이언트 증명서는 몇 가지 문제가 있다. 첫 번째는 증명서의 입수와 배포다. 유저가 클라이언트 증명서를 인스톨할 필요가 있고, 증명서는 유료로 구입할 필요가 있기 때문에 유저 수만큼 비용이 발생한다. 두번째는 클라이언트 인증서는 어디까지나 클라이언트의 실재를 증명할 뿐, 사용자의 존재 유무를 증명하는 증명서는 아니다.
  • OpenSSL 등의 소프트웨어를 사용하면 누구든지 인증 기관을 구축할 수 있어서 서버 증명서를 발행할 수 있다. 이렇게 독자적으루 구축한 인증 기관을 자기 인증 기관이라고 부른다. 이런 인증 기관의 증명서는 인터넷 상에서는 증명서의 구실을 하지 못하면 쓸모가 없다.
  • HTTPS의 통신 수순은 다음과 같다.
    1. 클라이언트가 Client Hello 메시지를 송신하면서, SSL 통신을 시작한다. 메시지에는 클라이언트가 제공하는 SSL 버전, 암호 스위스로 불리는 리스트(사용하는 암호화의 알고리즘이나 키 사이즈 등) 등이 포함된다.
    2. 서버가 SSL 통신이 가능한 경우에는 Server Hello 메시지로 응답한다. SSL 버전과 암호 스위트를 포함한다. 여기서 암호 스위트는 클라이언트에서 받은 암호 스위트의 내용에서 선택된 것이다.
    3. 서버가 Certificate 메시지를 송신한다. 메시지에는 공개키 증명서가 포함되어 있다. 전송이 끝나면 Server Hello Done 메시지를 송신하여 최초의 SSL 네고시에이션 부분이 끝났음을 알린다.
    4. SSL의 최초 네고시에이션이 종료되면 클라이언트는 인증서를 검증하고 Client Key Exchange 메시지로 응답한다. 메시지에는 통신을 암호화하는데 사용하는 Pre-Master secret이 포함되어있다. 이는 인증서에 포함되어있던 공개키로 암호화한다. 이 Pre-Master sceret을 이용해 master secret을 생성하고 이를 이용하여 공통키, 메시지 인증코드 등을 만들 수 있다.
    5. 클라이언트는 Change Cipher Spec 메시지를 송신한다. 이메시지는 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타내고 있다. 그리고 Fhinished 메시지를 송신한다. 이 메시지는 접속 전체의 체크 값을 포함하고 있다. 서버가 이 메시지를 올바르게 복호화할 수 있으면 네고시에이션이 성공한 것이다.
    6. 서버도 마찬가지로 Change Cipher Spec 메시지를 송신하고 Finished 메시지도 송신한다.
    7. Finished 메시지 교호나이 완료되면 SSL에 의해서 접속은 확립된다. 이후의 통신은 HTTP 리퀘스트와 리스폰스로 이루어진다.
    8. 마지막에 클라언트가 접속을 끊을때는 close_notify 메시지를 송신한다.
  • HTTPS는 SSL과 TLS라는 두 개의 프로토콜이 사용되고 있다. SSL은 원래 브라우저 개발 회사였던 넷스케이프가 내놓은 프로토콜로 SSL3.0까지는 같은 회사에서 개발되었다. 현재는 IETF로 옮겨져 SSL3.0을 기반으로 한 TLS1.0이 책정되어 TLS1.1, TLS1.2가 있다.
  • SSL 통신은 TCP 접속과 HTTP 리퀘스트, 리스폰스 이외의 추가적은 통신이 있어 통신 속도가 떨어진다는 문제점과 암호화 처리를 하는데 리소스가 다량으로 소비해야된다는 문제가 있다. 근본적인 해결책이 없기 떄문에 SSL을 처리하기 위한 전용 하드웨어인SSL 엑셀러레이터가 있다.

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

인증이란?

  • 서버에 액세스하고 있는 사람이 누군지 알기 위한 과정이다. 인증에는 주로 다음과 같은 것이 사용되고 있다.
    • 패스워드: 본인만이 알고 있는 문자열 정보
    • 원타임 토큰: 본인만이 가지고 있는 기기 등에 표시되는 한 번 쓰리고 버리는 패스워드 등의 정보
    • 전자 증명서: 본인(단말기)만이 가지고 있는 정보
    • 바이오 매트릭스: 지문이나 홍채 등의 본인의 신체 정보
    • IC 카드 등: 본인만이 가지고 있는 정보
  • HTTP/1.1에서 이요할 수 있는 인증 방식에는 다음과 같은 것이 있다.
    • BASIC 인증
    • DIGEST 인증
    • SSL 클라이언트 인증
    • 폼 베이스 인증

BASIC 인증

  • 과정
    1. 상태 코드 401로 응답해서 인증이 필요하다는 것을 전달
    2. 유저 ID와 패스워드를 Base64 인코드한 것을 송신
    3. 인증 성공 시에는 상태 코드 200으로 응답하고, 실패했을 경우에는 다시 상태코드 401로 응답
  • 하지만 이 방식에는 Base64가 암호화가 아니기 떄문에 HTTPS 등에서 암호화되지 않은 통신 경로 상에서 BASIC 인증을 해서 도청된 경우에는 복호화된 유저 ID와 패스워드를 빼앗길 가능성이 있다.
  • 또한 BASIC 인증을 하면, 일반 브라우저에서는 로그아웃할 수 없다는 문제도 있다.

DIGEST 인증

  • 과정
    1. 인증이 필요하다는 것을 전달하는 상태 코드 401로 응답하는 것과 함께 패스워드와 챌린지 코드(nonce)를 송신
    2. 패스워드와 챌린지 코드에서 리스폰스 코드(response)를 계산해서 송신
    3. 인증 성공 시에는 상태 코드 200으로 응답하고, 실패했을 경우에는 다시 401로 응답
  • DIGEST 인증에서는 패스워드의 도청을 방지하기 위한 보호 기능은 제공하고 있지만 이외에 위장을 방지하는 기능은 제공하고 있지 않는다.

SSL 클라이언트 인증

  • 유저 ID와 패스워드를 사용한 인증 방식은 이 두 가지 정보가 정확하다면 본인으로서 인증할 수 있다. 그러나 이 정보가 도난되었을 때에는 제 3자가 위장하는 경우가 있다. 이를 방지가위한 대책으로 SSL 클라이언트 인증이 사용된다.
  • 과정
    1. 인증이 필요한 리소스의 리퀘스트가 있는 경우에는 서버는 클라이언트에게 클라언트 증명서를 요구하는 “Certificate Request”라는 메시지를 송신한다.
    2. 유저는 송신하는 클라이언트 증명서를 선택한다. 그리고 클라이언트는 클라이언트 증명서를 송신한다.
    3. 서버는 클라이언트 증명서를 검증하여 검증 결과가 정확하다면 클라이언트의 공개키를 취득한다.
  • SSL 클라이언트 인증은 대부분의 경우 단독으로 사용되지 않고, 폼 베이스 인증과합쳐 2-factor 인증의 하나로서 이용되고 있다. SSL 클라이언트 인증을 사용하여 클라이언트의 컴퓨터를 인증하고 다른 인증 정보로서 패스워드를 사용하여 유저의 본인 확인을 한다.
  • SSL 클라이언트 에서는 클라어언트 증명서를 이용할 필요가 있다. 이 증명서를 이용하기 위해서는 상당한 비용이 필요하게 된다.

폼 베이스 인증

  • 폼 베이스 인증은 HTTP 프로토콜로서 사양이 정의되어 있는 인증 방식은 아니다.
  • 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(ID, 패스워드 등)를 송신하여 그 자격 정보의 검증 결과에 따라 인증하는 방식이다.
  • 공통 사양이 결정되어 있지 않은 폼 베이스 인증에서는 웹 사이트 별로 다르게 구현을 하고 있다.
  • 자주 사용되는 방법은 세션 관리를 위해서 쿠키를 사용하는 방법이다.
  • 과정
    1. 클라이언트가 서버에 유저 ID나 패스워드 등의 자격 정보를 포함한 리퀘스트를 송신한다. 보통 POST 메소드가 사용되어 엔티티 바디에 자격 정보를 저장한다. 이때, HTML 폼 화면 표시와 입력 데이터의 송신에는 HTTPS 통신을 사용한다.
    2. 서버 측은 유저를 식별하기 위해서 세션 ID를 발행한다. 클라이언트 측에 송신할 떄는 Set-Cookie 헤더 필드에 세션 ID를 저장해서 리스폰스를 반환한다. 도난당하거나 쉽게 유추되지 않도록 하기위해서 어려운 문자열을 사용하고 서버 측에서는 유효 기간을 관리하는 등 보안을 유지할 필요가 있다.
    3. 서버 측에서 세션 ID를 받은 클라이언트는 쿠키로 저장해 둔다.
  • 폼 베이스 인증에서는 자격 정보를 교환하는 방법은 표준화되어 있지 않을 뿐만 아니라 패스워드 등의 자격 정보를 서버 측에 어떻게 보존해야 하는지도 표준화되어 있지 않다. 일반적으로는 패스워드를 salt라는 부가 정보를 사용해서 해시 알고리즘으로 계산한 값을 저장한다.

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

HTTP를 기본으로 하는 프로토콜

  • HTTP의 규격이 만들어졌을 무렵에는 주로 HTML로 작성된 문서를전송하기 위한 프로토콜로 HTTP를 생각했었다.
  • 하지만 최근에는 용도가 변화하고 있어서 HTTP라는 프로토콜의 제한이나 한계가 있다.
  • HTTP의 기능이 부족하더라도 이미 웹 즈라우저라는 환경이 널리 퍼진 지금 HTTP라는 프로토콜은 무시할 수 없어서 HTTP를 기반으로 해서 여기에 추가하는 형태로 새로운 프로토콜이 몇 가지 구현되었다.

HTTP의 병목 현상을 해소하는 SPDY

  • 갱신된 정보를 가능한 빨리 실시간으로 표시하기 위해서는 서버상의 정보가 갱신되었을 때, 그것을 클라이언트의 화면에 반영할 필요가 있다. HTTP에서는 이 처리를 제대로 할 수가 없다.
  • HTTP에서는 서버의 정보가 갱신되었는지 아닌지 알기 위해서 클라이언트가 항상 서버 측에 확인하러 가야 한다. 만약, 서버 상의 정보가 갱신되지 않은 경우에는 불필요한 통신이 발생하게 된다. 현재 웹에 요구되고 있는 사용하는 방법으로 한다면 HTTP의 사양이 아래의 병목 현상이 발생한다.
    • 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
    • 리퀘스트는 클라이언트에서만 시작할 수 있다. 리스폰스만 받는 것은 불가능하다.
    • 리퀘스트/리스폰스 헤더를 압축하지 않는 체로 보낸다. 헤더의 정보가 많을수록 지연이 심해진다.
    • 장황한 헤더를 보낸다. 매번 같은 헤더를 보내는 것은 낭비다.
    • 데이터 압축을 임의로 선택할 수 있다. 압축해서 보내는 것이 강제적이지는 않다.
  • Ajax에 의한 해결 방법: Ajax는 JavaScript나 DOM 조작 등을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다. 이는 페이지의 일부분만 갱신되기 때문에 리스폰스로 전송되는 데이터 양은 줄어든다는 장점이 있다. 하지만 Ajax를 사용해서 실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생한다는 문제가 있다. 또한 HTTP의 프로토콜 자신이 가지고 있는 문제가 해결되는 것은 아니다.
  • Comet에 의한 해결 방법: Comet은 서버 측의 콘텐츠에 갱신이 있었을 경우, 클라이언트부터 리퀘스트를 기다리지 않고 클라이언트에 보내기 위한 방법이다. 통상 리퀘스트가 오면 리스폰스를 바로 반환하지만 Comet에서는 리스폰스를 보류 상태로 해두고, 서버의 콘텐츠가 갱신되었을 때에 리스폰스를 반환한다. 하지만 리스폰스를 보류하기 위해서 커넥션을 유지하는 시간이 길어진다. 커넥션을 유지하는 동안은 리소스를 소비한다. 또한 HTTP 자체의 문제가 해결되는 것은 아니다.
  • SPDY는 HTTP가 안고 있던 병목 현상을 프로토콜 레벨에서 해소하기 위해 개발이 진행되었다. (찾아보니 지금은 사용하지 않는다.)
  • SPDY는 HTTP를 완전히 바꿔 놓은 것이 아니라 TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다. 또한 SPDY는 보안을 위해 표준으로 SSL을 사용하도록 되어 있다.
  • SPDY는 HTTP에 다음과 같은 기능을 추가하고 있따.
    • 다중화 스트림: 단일 TCP 접속을 통해서 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있다. TCP의 효율이 높아진다.
    • 리퀘스트의 우선 순위 부여: 무제한으로 리퀘스트를 병렬 처리할 수 있지만, 각 리퀘스트에 우선 순위를 할당할 수 있다.
    • HTTP 헤더 압축: 리퀘스트와 리스폰스의 HTTP 헤더를 압축한다.
    • 서버 푸시 기능: 서버에서 클라이언트로 데이터를 푸쉬하는 서버 푸시 기능을 지원한다. 그래서 서버 측은 클라이언트 측의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.
    • 서버 힌트 기능: 서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안할 수 있다. 클라이언트가 자원을 발견하기 전에 리소스의 존재를 알 수 있기 때문에 이미 캐시를 가지고 있는 상태라면 불필요한 리퀘스트를 보내지 않아도 된다.
  • SPDY는 웹 콘텐츠 측은 특별히 의식할 필요가 없지만 웹 브라우저와 웹 서버에서 대응할 필요가 있다.
  • SPDY는 기본적으로 한 개의 도메인(IP주소)과의 통신을 다중화할 뿐이기 때문에 하나의 웹 사이트에서 복수의 도메인으로 리소스를 사용하고 있는 경우에는 그 효과가가 한정적이게 된다.
  • SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술이지만, 대부분 웹 사이트의 문제는 HTTP의 병목 현상 떄문만은 아니다. 웹 자신을 고속화하기 위해서는 웹 콘텐츠 제작을 개선하는 등 부수적으로 해야 할 일이 많다.

브라우저에서 양방향 통신을 하는 WebSocket

  • WebSocket은 HTTP와 다른 새로운 프로토콜이다. HTML5의 사양의 일부로서 책정되어 있지만, 2011년 기준 단독 프로토콜로 규격 책정이 진행되어있다.
  • WebSocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격이다. 웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML이나 이미지 등 임의 형식의 데이터를 보내게 된다.
  • WebSocket 프로토코르이 주요 특징은 다음과 같다.
    • 서버 푸시 기능: 서버에서 클라이언트에 데이터를 푸시하는 기능이다.
    • 통신량의 삭감: WebSocket은 접속을 한번 확립하면 접속을 유지하려고 한다. HTTP에 비해서 자주 접속하는 오버헤드가 적어지고, 헤더의 사이즈도 작기 떄문에 통신량을 줄일 수 있다.
    • 핸드쉐이크/리퀘스트: WebSocket 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드 쉐이크를 실시한다. Sec-WebSocket-Key에는 핸드쉐이크에 필요한 키가 저장되어 Sec-WebSocket-Protocol에는 사용하는 서브 프로토콜이 저장되어 있다. 서브 프로토콜은 WebSocket 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶을 떄에 이름을 붙여서 정의한다.
    • 핸드쉐이크/리스폰스: 앞선 리퀘스트에 대한 리스폰스는 상태 코드 101 Switching Protocols로 반환된다. Sec-WebSocket-Accept는 Sec-WebSocket-Key의 값에서 생성된 값이 저장된다. 핸드쉐이크에 의해 WebSocket 커넥션이 확립된 후에는 HTTP가 아닌, WebSocket 독자적인 데이터 프레임을 이용해 통신한다.

등장이 기다려지는 HTTP/2.0

  • HTTP/2.0은 사용자가 웹을 이용할 떄의 체감 속도의 개선을 목표로 하고 있다. HTTP/1.1 경유로 TCP를 사용하는 것이 기본으로 되어 있기 때문에 다음의 프로토콜이 베이스가 되어 사양이 검토되고 있다.(2012년 8월 13일 기준)
    • SPDY
    • HTTP Spped+Mobility
    • Network-Friendly HTTP Upgrade

웹 서버 상의 파일을 관리하는 WebDAV

  • WebDAV는 웹 서버의 콘텐츠에 대해서, 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1를 확장한 프로토콜이다.
  • 파일 작성이나 삭제 등 기본적인 기능 이외에 파일 작성자 등의 관리나 편집 중에 다른 유저가 다시 고쳐 쓰지 못하도록 잠금 기능, 갱신 정볼르 관리하는 리비전 기능 등이 있다.
  • HTTP/1.1의 PUT 메소드나 DELETE 메소드를 사용하면 웹 서버 상의 파일 작성이나 삭제 등을 할 수 있지만 보안이나 편의성등의 문제가 있어서 사용되고 있지 않다.
  • 서버 상의 리소스에 대해서 WebDAV에 새롭게 추가한 개념으로 다음과 같은 것이 있다.
    • 컬렉션(Collection): 여러 개의 리소스를 한꺼번에 관리하기 위한 개념이다. 각종 조작은 컬렉션 단위로 할 수 있다. 컬렉션 속에 컬렉션을 두어 사용할 수도 있따.
    • 자원(Resource): 파일이나 컬렉션을 리소스라고 부른다.
    • 프로퍼티(Property): 리소스의 프로퍼티를 정의한 것이다. 정의는 “이름=값” 형식으로 이루어진다.
    • 잠금(Lock): 파일을 편집할 수 없는 상태로 한다. 여러 명의 사람이 동시에 편집하는 경우 등 동시에 작성되는 걸 예방한다.
  • WebDAV에서는 리모트 파일 관리를 위해서 HTTP/1.1에 다음의 메소드가 추가되어 있다.
    • PROPFIND: 프로퍼티 취득
    • PROPPATCH: 프로퍼티 변경
    • MKCOL: 컬렉션 작성
    • COPY: 리소스 및 프로퍼티 복제
    • MOVE: 리소스 이동
    • LOCK: 리소스 잠금
    • UNLOCK: 리소스 잠금 해제
  • 메소드의 확장에 맞춰서 상태 코드도 확장되었다.
    • 102 Processing: 리퀘스트는 정상적으로 수신되었지만 아직 처리 중이다.
    • 207 Multi-Status: 복수의 스테이터스를 가지고 있다.
    • 422 Unprocessable Entity: ㅅ서기은 올바르지만 내용이 틀리다.
    • 423 Locked: 리소스가 잠겨져 있다.
    • 424 Failed Dependency: 어떤 리퀘스트와 관련된 리퀘스트가 실패했기 때문에 의존 관계를 유지 못한다.
    • 507 Insufficient Storage: 기억 영역이 부족하다.

왜 HTTP를 이렇게까지 사용되고 있는가?

  • 과거 네트워크를 이용한 시스템이나 소프트웨어를 새로 만들 때에는 필요한 기능을 구현한 새로운 프로토콜을만드는 경우가 있었다. 그러나 최근에는 HTTP를 사용하는 쪽이 대부분이다.
  • 많은 이유 중 하나로는 기업이나 조직 등의 방화벽 설정과 크게 관련되어 있다. 방화벽의 기본 기능 중에 지정된 프로토콜이나 포트 번호 이외의 패킷은 통과시키지 않는다는 기능이 있어 이로인해 새로운 프로토콜이나 포트 번호를 이용하는 경우에는 설정을 변경할 필요가 생긴다.
  • 웹은 HTTP에서 동작하고 있기 떄문에 웹 서버의 구축할 때나 웹 사이트에의 액세스에는 방화벽 설정에서 HTTP(80/tcp)이나 HTTPS(433/tcp)을 허가해둘 필요가 있다. 따라서 HTTP는 많은 회사나 조직에서 허가된 통신 환경인 경우가 많기 떄문에 방화벽의 설정을 변경할 필요가 없고 HTTP라면 도입이 용이하다는 장점이 있다.
  • 다른 이유로는 HTTP 클라이언트인 브라우저가 보급되어 있는 것이나 HTTP 서버가 많이 보급되고 있는 것 등의 이유도 있다.

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

HTML

  • HTML은 웹 상에서 하이퍼텍스트를 보내기 위해서 개발된 언어다. 하이퍼텍스트는 문서 시스템의하나로서, 문서 중에 임의의 장소가 다른 정보(문서나 이미지 등)를 링크한 문서다.
  • 마크업 언어는 문서의 일부에 특별한 문자열을 붙임으로써, 문서를 수식하는 언어다.
  • 1993년에 일리노이 대학의 NCSA에서 모자이크라는 브라우저가 발표되는데, 모자이크가 해석할 수 있는 HTML의 사양을 정리한 것이 HTML 1.0로 공개되었다.
  • 1999년 12월에 HTML 4.01이 출시 되었따.
  • 다음 저전인 HTML5는 2014년 정식으로 권고안이 발표되었다. HTML5는 브라우저 간의 호환성 문제를 해결하거나 텍스트를 데이터로서 다룰 수 있도록 하여 재사용하기 쉽게 하거나 애니메이션 등의 효과를 충실히 하는 것이 사양에 포함된다.
  • CSS는 HTML 각 요소를 어떻게 표시할지를 지시하는 것으로, 스타일 시트라고 불리는 사양 중의 하나다.

다이나믹 HTML

  • 다이나믹 HTML은 정적인 HTML 내용을 클라이언트 사이드 스크립트를 사용해서 동적으로 변경하는 기술을 말한다.
  • 다이나믹 HTML 기술은 HTML 등으로 만들어진 웹 페이지를 JavaScript 등의 클라이언트 사이드 스크립트로 조작하여 동적으로 변화시킨다. 동적으로 바꾸고 싶은 HTML 요소를 지정하기 위해서 DOM이라는 구조를 사용한다.
  • DOM은 HTML 문서와 XML 문서를 위한 API다. DOM을 사용하면 HTML 내의 요소를 오브젝트로 다룰 수 있기 때문에 요소 내의 문자열을 추출하거나 CSS를 프로퍼티로서 변경해 디자인을 변경할 수 있다.

웹 애플리케이션

  • 웹 기능을 사용해서 제공되는 프로그램을 웹 애플리케이션이라고 한다.
  • 본래 HTTP를 사용한 웹 구조는 사전에 준비된 콘텐츠를 클라이언트의 리퀘스트에 맞게 반환한다. 그러나 웹이 보급됨에 따라 이것만으로는 부족해서 프로그램으로부터 생성되는 동적 컨텐츠를 생성하는데 이를 웹 애플리케이션이라고 한다.
  • 웹 서버가 클라이언트에서 받은 리퀘스트를 프로그램에 전달하기 위한 구조를 CGI라고부른다. CGI는 리퀘스트에 맞게 컨텐츠를 동적으로 생성한다.
  • CGI를 사용하는 프로그램을 CGI 프로그램이라고 부른다.
  • 서블릿은 서버 상에서 동적 컨텐츠를 생성하기 위한 프로그램을 가리킨다. Java 프로그래밍 언어 사양의 하나로 엔터프라이즈 환경을 위한 Java인 JavaEE의 일부로서 제공되고 있다.
  • CGI는 리퀘스트마타 프로그램을 실행하기 때문에 대량으로 액세스가 있을 때 웹 서버에 부하가 있지만 서블릿에서는 프로세스 속에서 실행되기 때문에 비교적 부하를 적게하여 동작할 수 있다. 서블릿의 실행 환경을 컨테이노 혹은 서블릿 컨테이너라고 부른다.

데이터 송신에 이용되는 포맷이나 언어

  • XML은 목적에 맞게 확장 가능한 범용적으로 사용할 수 있는 마크업 언어다. XML은 HTML과 같은 문서 기술 언어에서 파생된 것이지만 HTML에 비해서 데이터를 기술하는 것에 특화되어있다.
  • RSS와 Atom은 뉴스나 블로그의 기사등의 갱신 정보를 송신하기 위한 문서포맷의 총칭으로 둘 다 XML을 이용하고있다. Atom의 경우는 Atom 전송 포맷과 Atom 출판 프로토콜이 있는데 단순히 Atom이라고 한 경우에는 Atom 전송 포맷을 가리킨다.
  • JSON은 경량 데이터 기술 언어로서 JavaScript에 있어서 오브젝트 표기법을 바탕으로 하고 있다. 단순하고 가볍게, 게다가 문자열을 JavaScript에서 간단하게 읽어올 수 있다는 점에서 Ajax에서 널리 이용하게 되었다.

웹 공격 기술

웹 공격 기술

  • HTTP는 구조가 단순하기 떄문에 인증이나 세션 관리, 암호화 등의 보안 기능이 없다. 따라서 이를 개발자가 직접 설계하고 구현할 필요가 있다. 제각각이 설계하기 떄문에 각기 다르게 구현된다. 그 겨로가, 보안 등급이 충분치 못하고 공격자가 악용할 수 있는 취약성과 같은 버그가 있는 상태로 가동되고 있는 웹 애플리케이션이 있다.
  • 웹 애플리케이션이 브라우저로부터 수신한 HTTP 리퀘스트의 내용을 자유롭게 변경하고 변조할 수 있다. 그렇기 떄문에 웹 애플리케이션이 기대하고 있는 값과 다른 값이 보내질 가능성이 있다.
  • 웹 애플리케이션에 대한 공격 패턴은 2가지가 있다.
    • 능동적 공격: 공격자가 직접 웹 애플리케이션에 액세스해서 공격 코드를 보내는 타입의 공격이다. SQL 인젝션과 OS 커맨드 인젝션 등이 있다.
    • 수동적 공격: 함정을 이용해서 유저에게 공격 코드를 실행 시키는 공격이다. 수동적 공격의 일반적인 순서는 다음과 같다.
      • 공격자가 설치한 함정에 유저를 유도한다. 함정에는 공격 코드를 심어둔 HTTP 리퀘스트를 발생시키기 위한 장치가준비되어 있다.
      • 사용자가 함정에 걸리면 유저의 브라우저나 메일 클라언트에서 함정을 열게 됩니다.
      • 함정에 걸리면 유저의 브라우저가 장착된 공격함 HTTP 리퀘스트를 공격 대상인 웹 애플리케이션에 포함한 HTTP 리퀘스트를 공격 대상인 웹 애플리케이션에 송신하고 공격 코드를 실행한다.
      • 공격 코드를 실행하면 취약성이 있는 웹 애플리케이션 경유한 결과로서 유저가 가지고 있는 쿠키 등의 기밀 정보를 도둑맞거나 로그인 중인 유저의 권한이 악용되는 등의 피해가 발생한다. 수동적 공격에는 크로스 사이트 스크립팅(XSS)과 크로스 사이트 리퀘스트 포저리(CSRF) 등이 있다. 수동적 공격을 이용하면 인트라넷 같은 인터넷에서 직접 액세스할 수 없는 네트워크를 공격할 수 있다.

출력 값의 이스케이프 미비로 인한 취약성

  • 웹 애플리케이션의 보안 대책을 실시하는 장소는 크게 나누면 다음과 같다.
    • 클라이언트에서 체크: 대부분 JavaScript를 사용한다. 그러나 변조 되었거나 부효화될 가능성이 있기 때문에 근본적인 보안 대책으로는 적합하지 않다. 클라이언트 측의 체크는 입력 실수를 바로 지적해 주는 정도의 UI 향상의 용도다.
    • 웹 애플리케이션(서버 측)에서 체크
      • 입력값 체크: 웹 애플리케이션 내에서 처리할 때에 공격 코드로서 의미를 갖는 것도 있기 때문에 근본적인 보안 대책으로는 적합하지 않다. 입력 값 체크는 시스템 요컨대로 된 값인지 아닌지에 대한 체크나 문자 코드의 체크 등을 실시한다.
      • 출력값 체크: 출력하는 곳에 따라 값을 이스케이프 처리하는 출력 값의 이스케이프가 보안 대책으로 중요하다.
  • 크로스 사이트 스크립팅: 취약성이 있는 웹 사이트를 방문한 사용자의 브라우저에 부정한 HTML 태그나 JavaScript 등을 동작시키는 공격이다. 크로스 사이트 스크립팅에 의해 다음과 같은 영향을 받을 수 있다.
    • 가짜 입력 폼 등에 의해 유저의 개인 정보를 도둑 맞는다
    • 스크립트에 의해 유저의 쿠키 값이 도둑맞거나 피해자가 의도하지 않는 리퀘스트가 송신된다.
    • 가짜 문장이나 이미지 등이 표시된다.
  • SQL 인젝션: 웹 애플리케이션을 이용하고 있는 데이터베이스에 SQL을 부정하게 실행하는 공격이다. SQL 인젝션에 의해 다음과 같은 영향을 받을 수 있다.
    • 데이터베이스 내의 데이터 부정 열람이나 변조
    • 인증 회피
    • 데이터베이스 서버를 경유한 프로그램 실행 등
  • OS 커맨드 인젝션: 웹 애플리케이션을 경유하여 OS 명령을 부정하게 실행하는 공격이다.
  • HTTP 헤더 인젝션: 공격자가 리스폰스 헤더 필드에 개행문자를 삽입함으로써 리스폰스 헤더 필드나 바디를 추가하는 공격이다. 특히 바디를 추가하는 공격은 HTTP 리스폰스 분할 공격이라고 부른다. HTTP 헤더 인젝션에 의해서 다음과 같은 영향을 받을 수 있다.
    • 임의의 쿠키 세트
    • 임의의 URL에 리다이렉트
    • 임의의 바디 표시(HTTP 리스폰스 분할 공격)
  • 메일 헤더 인젝션: 메일 송신 기능에 임의의 To 및 Subject 등의 메일 헤더를 부정하게 추가하는 공격이다.
  • 디렉터리 접근 공격: 디렉토리 트래버설이라고 부르면 비동개 디렉토리의 파일에 대해서 부정하게 디렉토리 패스를 가로질러 액세스하는 공격이다. 웹 애플리케이션에서 파일 이름으을 외부에서 지정하는 처리가 약할 경우, 상대 경로나 절대 경로를 지정하여 임의의 파일이나 디렉터리에 접근할 수 있다. 출력 값의 이스케이프의 문제로 볼 수도 있지만 임의의 파일 이름을 지정할 수 없도록 해야한다.
  • 리모트 파일 인클루션: 스크립트의 일부를 다른 파일에서 읽어올 때 공격자가 지정한 외부 서버의 URL을 파일에서 읽게 함으로써 임의의 스크립트를 동작시키는 공격이다. 출력 값의 이스케이프 문제로 볼 수 있지만 임의의 파일명을 지정할 수 없도록 해야한다.

웹 서버의 설정이나 설계 미비로 인한 취약성

  • 강제 브라우징: 웹 서버의 공개 디렉터리에 있는 파일 중에서 공개 의도가 없는 파일이 열담되게 되는 취약성이다. 강제 브라우징으로 인해 다음과 같은 영향을 받을 수 있다. 공개하고 싶지 않은 URL을 숨기는 보안 대책에 의존하고 있는 경우 해당 URL을 알게 되면 파일을 열람할 수 있다는 문제점이 있다. 디렉터리 이름, 추측하기 쉬운 파일명, 에디트 소프트웨어 등에서 자동 생성하는 백업 파일, 인증 후에만 표시되어야만 하는 파일 등이 피해 대상이 될 수 있다.
    • 고객 정보 등 중요 정보 누설
    • 본래 액세스 권한이 있는 사용자에게만 표시하지 않는 정보 누설
    • 어디에서도 링크되지 않는 파일 누설
  • 부적절한 에러 메시지 처리: 공격자에게 유익한 정보가 웹 애플리케이션의 에러 메시지에 포함되는 취약성이다. 주요 에러 메시지는 다음과 같은 것이 있다.
    • 웹 애플리케이션에 의한 에러 메시지
    • 시스템에 의한 에러 메시지
      • PHP나 ASP 등의 스크립트 에러
      • 데이터베이스나 미들웨어의 에러
      • 웹 서버 에러
  • 오픈 리다이렉트: 지정한 임의의 URL로 리다이렉트 하는 기능이다. 이를 사용하는 경우 URL에 악의가 있는 웹 사이트가 지정된 경우 유저가 그 웹 사이트로 유도되는 취약성이 있다.

세션 관리 미비로 인한 취약성

  • 세션 하이잭: 공격자가 어떠한 방법으로 유저의 세션 ID를 입수해서 악용하는 것으로, 유저로 위장하는 공격이다. 공격자가 세션 ID를 입수하는 방법에는 주로 다음과 같은 것이 있다.
    • 부적절한 생성 방법에 의한 세션 ID 추측
    • 도청이나 XSS 등에 의한 세션 ID 도용
    • 세션 고정 공격에 의한 세션 ID 강제
  • 세션 픽세이션: 공격자가 지정한 세션 ID를 유저에게 강제적으로 사용하게 하는 공격으로 수동적 공격이다. 세션 고정 공격이라고도 부른다. 공격 사례는 다음의 순서로 이루어져있다. 만약 PHP나 ASP.NET 등에 존재하는 미지의 세션 ID를 받아들이는 기능인 세션 어댑션을 사용하면, 아래의 세션 ID 준비 단계가 필요없어진다. 공격자가 마음대로 세션 ID를 만들면 되기 때문이다.
    1. 공격자는 함정의 준비를 위해 웹 사이트에 액세스해서 세션 ID를 입수한다. 이 때 세션 ID는 인증 전 상태로 기록되어있다.
    2. 공격자는 이 세션 ID를 유저가 강제적으로 이용하도록 함정을 준비하고, 유저가 그 세션 ID를 사용해 인증하도록한다.
    3. 공격자는 사용자가 함정에 걸린 시기를 가늠해서 조금 전의 세션 ID를 이용해 웹 사이트에 엑세스한다.
  • 크로스 사이트 리퀘스트 포저리(CSRF): 인증된 유저가 의도하지 않은 개인 정보나 설정 정보 등을 공격자가 설치해 둔 함정에 의해 어떤 상태를 갱신하는 처리를 강제로 실행시키는 공격으로 수동 공격이다. 크로스 사이트 리퀘스트 포저리는 다음과 같은 영향을 받을 수 있다.
    • 인증된 유저의 권한으로 설정 정보 등을 갱신
    • 인증된 유저의 권한으로 상품을 구입
    • 인증된 유저의 권한으로 게시판에 글 작성

기타

  • 패스워드 크래킹: 패스워드를 논리적으로 이끄러내서 인증을 돌파하는 공격이다. 패스워드 크래킹에는 다음과 같은 방법이 있다.
    • 네트워크 경유로 패스워드 시행: 웹 애플리케이션이 제공하는 인증 기능에 대해서 네트워크 경유로 패스워드 후보를 시험해 보는 공격이다.
      • 무차별 대입 공격: 비밀 번호 시스템에서 취할 수 있는 모든 패스워드 후보를 시험해서 인증을 돌파하는 공격이다.
      • 사전 공격: 가전에 패스워드 후보를 준비해두고 그것을 시험해 봄으로써 인증을 돌파하는 공격이다.
    • 암호화된 패스워드를 해독: 공격자가 어떠한 수단으로 패스워드를 훔쳤다 하더라도 이를 이용하기 위해서 해독하는 등 평문을 손에 넣어야한다.
      • 무차별 대입 공격/사전 공격에 의한 유추: 패스워드 후보에 같은 해시 함수를 적용해 시험해 보면서 해시 값을 만들어 내어 확인하는 방법이다.
      • 레인보우 테이블: 평문과 그에 대응하는 해시 값으로 구성된 데이터베이스 테이블을 미리 마련해두고 해시 값을 검색해서 평문을 찾는다. 해시 함수를 미리 적용해두었으므로 공격하는 시간이 줄어든다.
      • 열쇠 입수: 패스워드의 데이터가 공통키 암호 등으로 암호화도어 있을 때 암호화에 사용된 키를 입수하는 방법이다.
      • 암호 알고리즘의 취약성: 암호 알고리즘의 취약성을 파고들어 패스워드를 해독하는 방법이다.
  • 클릭 재킹: 투명한 버튼인 링크를 함정으로 사용할 웹페이지에 심어두고, 유저에게 링크를 클릭하게 함으로써 의도하지 않은 콘텐츠에 액세스 시키는 공격이다.
  • DoS 공격: 서비스 제공을 정지 상태로 만드는 공격이다. 서비스 정지 공격 또는 서비스 거부 공격이라고도 불린다. 웹 사이트만이 아니라 네트워크 기기나 서버 등을 대상으로 공격할 수도 있다. 주요 DoS 공격에는 다음과 같은 방법이 있다.
    • 액세스를 집중시킴으로써 부하를 걸어 리소스를 다 소비하게 해 사실상 서비스를 정지 상태로 만든다.
    • 취약성을 공격해 서비스를 정지시킨다.
  • 백도어: 제한된 기능을 정규 절차를 밟지 않고 이용하기 위해서 살치된 뒷문이다. 주요 백도어에는 다음과 같은 종류가 있다. 백도어용 프로그램이 설치된 경우에는 프로세스나 통신을 감지해서 발견하는 것도 가능하지만, 웹 애플리케이션을 수정해서 설치한 백도어는 정상적으로 이용하는 것과 구별하기 어렵기 때문에 발견하기가 힘들다.
    • 개발 단계에서 디버그용으로 추가한 백도어
    • 개발자가 자신의 이익을 위해서 추가한 백도어
    • 공격자가 어떠한 방법을 써서 설치한 백도어

댓글남기기