HTTP와 네트워크

웹과 네트워크의 기본

• 인터넷을 포함하여 일반적으로 사용하는 네트워크는 TCP/IP라는 프로토콜에서 움직임. HTTP는 그 중 하나임.

• 프로토콜 - 서로 다른 하드웨어와 운영체제 등을 가지고 통신 하기 위한 모든 요소에 대한 규칙.

• TCP/IP - 인터넷에 관련된 다양한 프로토콜 집합의 총칭

역할

• 애플리케이션 계층 - 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정. ex) FTP, DNS, HTTP

• 트랜스포트 계층 - 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공함. ex) TCP, UDP

• 네트워크 계층 - 네트워크 상에서 패킷(전송하는 데이터의 최소 단위)의 이동을 다룸. 인터넷의 경우 상대 컴퓨터에 도달하는 동안 여러 가지 네트워크 기기 선택지 중에서 하나의 길을 결정함. ex) IP

• 링크 계층 - 하드웨어적 측면을 다룸. ex) 디바이스 드라이버, NIC, 케이블

로직

1. 송신측 클라이언트의 애플리케이션 계층에서 어느 웹 페이지를 보고 싶다라는 HTTP 리퀘스트를 지시.

2. 트랜스포트 계층(TCP)에서는 애플리케이션 계층에서 받은 데이터(HTTP 메시지)를 통신하기 쉽게 조각내어 안내 번호와 포트 번호를 붙여 네트워크 계층에 전달.

3. 네트워크 계층(IP)에서는 수신지 MAC 주소를 추가해 링크 계층에 전달.

4. 네트워크 송신 준비 완료.

5. 수신측 서버는 링크 계층에서 데이터를 받아 순서대로 위의 계층에 전달.

6. 애플리케이션 계층에 도달하면 클라이언트가 발신했던 HTTP 리퀘스트 내용을 수신할 수 있음.

장점

• 계층화되어 있어 어디선가 사양이 변경되었을 때 변경된 해당 계층만 바꾸면 됨(캡슐화).

간단한 프로토콜 HTTP

• HTTP는 클라이언트와 서버 간의 리퀘스트, 리스폰스를 교환하며 통신함.

• HTTP는 상태를 유지하지 않음(stateless). 데이터를 빠르고 확실하게 처리하는 범위성을 확보하기 위함.

• 로그인 등 상태를 유지하고 싶은 욕구에 부응하기 위해 쿠키라는 기술 도입. 쿠키는 리퀘스트와 리스폰스에 쿠기 정보를 추가해 클라이언트 상태를 파악할 수 있음.

• HTTP는 리퀘스트 URL를 사용하여 인터넷 상의 리소스를 식별하고 지정함.

• HTTP 메소드는 서버에 GET, POST 등을 통해 임무를 부여함.

• 지속 연결로 접속량을 절약함. 지속 연결은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지함 → 오버헤드를 줄여 서버에 대한 부하 경감, 웹 사이트 빨리 표시. 발전 과정 : 개별연결 → 지속연결 → 파이프라인화 (여러 리퀘스트를 보냄.)

HTTP 정보는 HTTP 메시지에 있다

http request and response message structure

인코딩

• Message - HTTP 통신의 기본 단위, Entity - request, response의 payload(부가물)로 전송되는 정보. 기본적으로 이 둘은 같짐만 전송 코딩이 적용된 경우엔 entity 바디의 내용이 변화하기 떄문에 message 바디와 달라짐.

• 콘텐츠 코딩 - entity를 작게 압축해서 송신하는 인코딩 방식. 클리이언트 측에서 디코딩함.

• Chunked transfer coding(청크 전송 코딩) - 사이즈가 큰 데이터를 전송하는 경우 entity 바디를 분할 하는 기능.

그 외

• 이미지나 텍스트 파일 등을 업로드할 때, multipart(여러 다른 종류의 데이터)에 대응하여 하나의 메시지 바디 내부에 엔티티를 여러 개 포함시켜 내보낼 수 있음.

• Range request - 다운로드 중 커넥션이 끊어지는 경우 등에 대비하여 범위를 지정하여 request함.

• Content Negotiation - 언어가 여러 개인 웹페이지처럼 같은 내용이지만 여러 개의 페이지를 지닌 웹 페이지의 리소스 내용에 대해 교섭하는 것.

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

HTTP와 연계하는 웹 서버

• 가상 호스트 기능을 사용하면 서버 1대로 여러 대가 있는 것처럼 설정 가능.

• proxy, gateway, tunnel과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능. 네트워크 대역 효율적으로 사용, 엑세스 제한을 목적으로 사용함.

• 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킴. 캐시를 사용하면 리소스를 가진 서버에 액세스를 줄여 통신량과 통신 시간을 절약할 수 있음.

• 클라이언트 쪽 브라우저가 유효한 캐시를 가지고 있는 경우, 서버에 엑세스하지 않음.

HTTP 헤더

• HTTP의 리퀘스틍와 리스폰스에는 반드시 HTTP 헤더가 포함되어 있음.

• 메시지 바디의 크기나 사용하고 있는 언어, 인증 정보 등을 브라우저나 서버에 제공하기 위해 사용됨.

//헤더 필드 구조 - 콜론으로 나뉘어져 있음.
헤더 필드 명 : 필드 값

• 4종류가 있음.
• 일반적 헤더 필드
• 리퀘스트 헤더 필드
• 리스폰스 헤더 필드
• 엔티티 헤더 필드

Authorization

• ex) Authorization : Basic dWVub...

• 유저 에이전트의 인증 정보를 전달하기 위해 사용함.

• 통상 서버에 인증 받으려 하는 유저 에이전트는 상태 코드 401 리스폰스의 뒤에 리퀘스트에 authorization 헤더 필드를 포함함.

Content-Type

• 메시지 바디의 오브젝트 타입을 가리킴. ex) Content-Type:text/html

• 필드 값은 타입/서브 타입으로 기록함.

쿠키를 위한 헤더 필드

• 쿠기는 서버와 클라잉언트 간의 상태를 관리하기 때문에 유저 식별과 상태 관리에 사용됨.

• 웹 사이트가 유저의 상태를 관리하기 위해 웹 브라우저 경유로 유저의 컴퓨터 상에 일시적으로 데이터를 기록해 두고, 다음에 그 유저가 웹 사이트에 액세스 해 왔을 때 지난번에 발행한 쿠기를 송신받을 수 있음.

• set-Cookie : 상태 관리 개시를 위한 쿠기 정보(리스폰스), Cookie : 서버에서 수신한 쿠기 정보(리퀘스트)

• set-Cookie 필드 속성으로 NAME=VALUE, Expires=DATE, path=PATH, HttpOnly 등이 있음.

웹을 안전하게 지켜주는 HTTPS

HTTP의 약점

• 평문(암호화 하지 않은) 통신이기 때문에 도청 가능.
• TCP/IP의 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있음.
• 암호화로 도청을 피할 수 있음.
• 통신 암호화 - SSL, TLS 등 다른 프로토콜을 조합함으로써 통신 내용 암호화.
• 콘텐츠 암호화 - 통신 자체는 두고 메시지 바디(콘텐츠)를 암호화.

• 통신 상대를 확인하지 않기 때문에 위장 가능.
• SSL로 확인 가능. SSL은 암호화 뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공함.

• 완전성을 증명할 수 없기 때문에 변조 가능. 리퀘스트와 리스폰스가 같은지 확인할 수 없음.
• 클라이언트에 다운로드 파일에 악성 코드를 심어놓을 수 있음 (중간자 공격).
• PGP, MD5, SHA-1 등의 해시 값, 디지털 서명을 확인하는 방법이 있으나 확실한 것은 아님.

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

• HTTP에 암호화, 인증 등의 구조를 더한 것을 HTTS(HTTP Secure)라고 부름.

• HTTP는 직접 TCP와 통신하지만 HTTP는 SSL과 통신하고 SSL이 TCP와 통신함.

• 암호화 방식으로 공개키 암호화, 공개키와 비밀키 암호화, 공개키를 증명하는 증명서, EV SSL 증명서 등이 있음. HTTPS는 하이브리드 암호 시스템임.

1. 클리언트가 Client Hello 메시지를 송신하면서 SSL통신 시작. SSL 버전 지정, 암호 스위트로 불리는 리스트 등이 포함.

2. 서버가 통신이 가능할 경우 응답함. 클라이언트에서 받은 암호 스위트 내용에서 선택한 내용 선택.

3. 서버가 certificate 메시지 송신. 메시지에는 공개키 증명서 포함.

4. 서버가 Server Hello Done을 송신하여 최초 SSL 네고시에이션 종료 통지.

5. 클라이언트가 Client key Exchange 메시지 응답. 3번의 공개키 중 증명서에서 꺼낸 공개키로 암호화된 pre-Master-secret로 통신 암호화.

6. 클라이언트는 Change Cipher Spec 메시지를 송신. 이 메시지는 이후 통신은 암호키를 사용해야함을 나타냄,

7. 클라이언트는 Finished 메시지 송신. 네고시에이션 성공 여부는 서버의 복호화 유뮤에 따라 달라짐.

8. 서버도 change cipher spec 송신.

9. 서버도 Finished 메시지 송신.

10. 서버와 클라이언트의 Finished 메시지 교환이 이뤄지면 SSL에 의해 접속 확립. 여전히 통신은 SSL에 의해 보호됨. 이제 어플리케이션 계층의 프로토콜에 의해 통신. HTTP 리퀘스트 송신.

11. HTTP 리스폰스 송신.

12. 클라이언트의 접속 종료. 이때 close_notify 메시지 송신. 이후 TCP FIN 메시지를 보내 TCP 통신 종료.

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

• 특정 인물에게만 보여주고 싶은 페이지 등 인증이 필요함.

• 시스템에 엑세스하는 권한을 가진지 확인하기 위해 다음과 같은 것이 사용됨.
• 패스워드 - 문자열 정보.
• 원타임 토큰 - 본인 소유 기기 등에 표시되는 한 번 쓰고 버리는 패스워드 등의 정보.
• 전자 증명서 - 본인(단말기)만이 갖고 있는 정보.
• 바이오 매트릭스 - 지문, 홍채 등 신체 정보.
• IC 카드 등 - 본인만이 가지고 있는 정보.

HTTP에서 사용하는 인증정보

• BASIC 인증 - 웹 서버와 대응하고 있는 클라이언트 사이에서 이뤄지는 인증 방식.

1. 리퀘스트 송신. 2. 상태 코드 401로 응답해서 인증이 필요하다는 것을 전달. 3. 유저 ID와 패스워드르르 Base64 형식으로 인코드한 것을 송신. 4. 인증 성공 시 상태 코드 200으로 응답, 실패 시 다시 상태 코드 401로 응답.

Base64는 암호화가 되지 않아 부가 정보 없이 복호화가 가능함. 즉, HTTPS 등에서 암호화되지 않은 통신 경로 상에서 복호화된 유저 ID와 패스워드를 빼앗길 가능성이 있음. 또한, 일반 브라우저에서 한번 인증 시 로그아웃을 할 수 없음. 그다지 사용되지 않는 방식.
 

• DIGEST 인증

1. 리퀘스트 송신. 2. 인증을 요구하는 상태 코드 401로 응답 + 패스워드, 챌린지 코드(nonce) 송신. 3. 패스워드와 챌린지 코드에서 리스폰스 코드를 계산하여 송신. 4. 인증 성공 시 상태 코드 200으로 응답, 실패 시 다시 상태 코드 401로 응답.

챌린지 리스폰스 방식은 최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해 리스폰스 코드를 계산함. 이 값을 상대에게 송신하여 인증하는 방식. BASIC보단 높은 보안 등급을 제공하지만, HTTPS의 클라이언트 인증 등과 비교하면 낮음. 웹 사이트에서 요구되는 보완 등급에는 미치지 못한다는 점에서 사용되지 않음.
 

• SSL 클라이언트 인증
• HTTPS의 클라이언트 인증서를 이용한 인증 방식.
• 사전에 등록된 클라이언트에서의 액세스인지 아닌지를 확인할 수 있음.
• 그러기 위해 사전에 클라이언트에 클라이언트 증명서를 배포하고 인스톨 해둘 필요가 있음.

1. 서버는 클라이언트에게 클라이언트 증명서를 요구함(Certificate Request 메시지 송신). 2. 유저는 송신하는 클라이언트 증명서를 선택(Client Certificate 메시지 송신). 3. 서버는 클라이언트 증명서를 검증하여 맞다면 클라이언트의 공개키 획득. 이 후 HTTPS에 의한 암호 개시.

• 클라이언트 인증은 2-factor(다른 폼 베이스 인증과 합쳐 인증함) 인증에서 사용.
• 첫 번째 인증 정보로서 SSL 클라이언트 인증을 사용하여 클라이언트의 컴퓨터를 인증하고, 다른 인증 정보로서 패스워드를 사용하여 유저의 본인 확인 진행.
• 보안 등급이 높기 때문에 도입 비용, 운용 비용 등의 문제로 널리 사용되지 않음.
 

• 폼 베이스 인증
• 구글 로그인 등이 있음.
• 표준적인 사양은 없지만 일반적으로 세션 관리를 위해 쿠키를 사용함.
• 인증 자체는 클라이언트가 송신해온 유저 ID와 패스워드가 사전에 등록하고 있는 것과 일치하는지를 검증하며 이루어짐.
• 다만 HTTP는 스테이트리스 프로토콜이기 때문에 상태 유지가 어려움. 즉, 상태 관리가 안되기 때문에 세션 관리와 쿠키를 이용하여 상태 관리 기능 보충.

1. 클라이언트가 자격 정보(유저 ID, 패스워드) 전달. 2. 서버 측은 유저 식별을 위한 세션 ID를 발행하여 쿠키로 송신함. 세션 ID는 추측하기 어려운 문자열을 사용하고 유효 기간을 관리하는 등 보안을 유지해야 함. 3. 클라이언트는 세션 ID를 쿠키로 저장함. 리퀘스트 시 브라우저가 자동으로 송출하여 송신.

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

Ajax(Asynchronous JavaScript And XML)

• JS나 DOM 조작을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법.

• 페이지의 일부분만 갱신되기 때문에 리스폰스로 전송되는 데이터 양은 줄어든다는 장점.

• 다만 Ajax를 이용해 실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생하는 문제점이 있음.

WebSocket

• Ajax의 XMLHttpRequest의 결점을 해결하기 위한 기술.

• WebSocket은 웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML이나 이미지 등 임의 형식의 데이터를 보냄.

• 서버와 클라이언트 어느 쪽에서도 송신을 할 수 있게 됨.

• WebSocket 프로토콜의 주요 특징
• 서버 푸시 기능
• 통신량의 삭감
• 핸드쉐이크/리퀘스트 - HTTP에 접속을 확립하려면 핸드쉐이크 절차를 밟아야 함.
• 핸드쉐이크/리스폰스
• WebSocket API - JS에서 양방향 통신을 하기 위해서는 W3C에서 사양이 책정되어 있는 WebSocket 인터페이스를 사용함.

HTTP/2.0

• HTTP/2는 HTTP에 대항하여 완전히 새로운 프로토콜을 만들었기 보단 성능향상에 초점을 맞춘 프로토콜임.

• HTTP 메소드, 상태 코드 및 의미는 동일하며 프로토콜을 나타 내기 위해 HTTP/ 1.x와 동일한 API (일부 작은 추가 기능 포함)를 사용 할 수 있어야 함.

• HTTP/2의 초점은 성능에 있음. 

• 특히 최종 사용자가 대기 시간, 네트워크 및 서버 리소스 사용을 인식함.

• 주요 목표 중 하나는 브라우저에서 웹 사이트로의 단일 연결을 허용하는 것.

• 웹 응답 속도가 HTTP/1.1에 비해 15~50%가 향상됨.

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

HTML

• 웹 상에서 하이퍼텍스트를 보내기 위해서 개발된 언어.

• 문서를 수식함.

• HTML5는 브라우저 간의 호환성 문제를 해결하거나 텍스트를 데이터로서 다룰 수 있도록 하여 재사용하기 쉽게 하거나 애니메이션 등의 효과를 충실히 하는 것이 사양에 포함됨.

• CSS로 브라우저에서 보이는 외관을 변경할 수 있음.

다이나믹 HTML

• 정적인 HTML 내용을 클라이언트 사이드 스크립트를 사용해 동적으로 변경하는 기술.

• 동적으로 바꾸고 싶은 HTML 요소를 지정하기 위해 DOM 구조를 사용함.

• DOM(Document Obejct Model)은 HTML 문서와 XML 문서를 위한 API.

• DOM을 사용하면 HTML 내의 요소를 오브젝트로 다룰 수 있기 때문에 요소 내의 문자열을 추출하거나 CSS를 프로퍼티로서 변경해 디자인을 변경할 수 있음.

웹 애플리케이션

• 웹 기능을 사용해서 제공되는 프로그램을 지칭함. ex) 쇼핑 사이트, 인터넷 뱅킹, SNS, 게시판, 검색 엔진, e-러닝

• 웹 서버와 프로그램을 연계하기 위해 CGI(Common GateWay Interface)로 웹 서버가 클라이언트에서 받은 리퀘스트를 프로그램에 전달하기 위한 구조를 사용함. ex) Perl, PHP, Ruby, C언어

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

• XML - 목적에 맞게 확장 가능한 범용적으로 사용할 수 있는 마크업 언어.
• HTML은 브라우저같이 레이아웃을 잡아주지 않는다면 가독성이 떨어짐. 반면 XML은 HTML과 같이 태그를 사용하 트리 구조로 되어 있고 독자적으로 확장된 태그가 정의되어 있음.
• 데이터를 재사용하기 쉬움.

• JSON - 경량 데이터 기술 언어로서 JS에 있어서 오브젝트 표기법을 바탕으로 하고 있음.
• JS에서 이용하기쉽고 가벼움.
• 다룰 수 있는 데이터 형은 false, null, true, 오브젝트, 배열, 수치, 문자열 등 일곱 가지 종류.

웹 공격 기술

크로스 사이트 스크립팅(XXS)

• 취약성이 있는 웹사이트를 방문한 사용자의 브라우저에서 부정한 HTML 태그나 JS 등을 동작시키는 공격.

• 공격 받는 유형 예시
• 가짜 입력 폼 등에 의해 유저의 개인 정보를 도둑 맞는다.
• 스크립트에 의해 유저의 쿠키 값이 도둑맞거나 피해자가 의도하지 않는 리퀘스트가 송신됨.
• 가짜 문장이나 이미지 등이 표시됨.

Dos(Denial of Service attack) 공격

• 서비스 제공을 정리 상태로 만드는 공격.

• 공격 유형
• 액세스를 집중시킴으로써 부하를 걸어 리소스를 다 소비하게 해 사실상 서비스를 정지 상태로 만든다.
• 취약성을 공격해 서비스를 정지시킨다.

• 대량의 엑세스를 보낸다는 점에서 단순해 보이지만, 공격 이외의 정상적인 액세스와 구별이 힘들다는 이유도 있어 방지하는 것이 쉽지 않음.