[Network] HTTP 개념

HTTP(HyperText Transfer Protocol)

웹에서 클라이언트에서 서버까지의 일련의 흐름을 결정하는 것

ex. 웹브라우저(클라이언트)가 주소 입력란에 url을 입력시 서버의 리소스를 요청하고 서버가 http로 통신한다. 

 

http는 하나의 요청에 대해 하나의 응답을 반환하는 아주 간단한 프로그램

-> 실제 페이지를 구성하고 있는 파일 수 만큼 이 작업을 반복한다.

http는 '요청된 데이터를 반환하는 것' 만을 목적으로 만들어졌다.

-> 한번의 요청과 응답으로 통신은 완결되고, 과거에 수행한 통신과 관련을 가지는 경우가 없다.

한번에 끝나는 프로토콜 : 무상태 프로토콜(Stateless protocol)

---

IP/TCP/DNS

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

배송을 담당하는 IP

IP(Internet Protocol) 은 네트워크 계층에 위치한 프로토콜로 각각의 패킷을 상대방에게 전달

* 상대방에게 전달하기 위해서는 각 네트워크 카드에 할당된 고유 주소인 MAC 주소와 각 노드에 부여된 IP 주소가 필요하다.

통신은 ARP를 이용하여 MAC 주소에서 한다.

ARP(Address Resolution Protocol) 로 수신지의 IP주소를 바탕으로 MAC주소를 조사하는 역할을 한다.

 

신뢰성을 담당하는 TCP

TCP(Transfer Control Protocol)는 트랜스포트 층에 위치하고 있다.

용량이 큰 데이터를  TCP 세그먼트(단위패킷)로 작게 분해하여  상대에게 전달하고, 정확하게 도착했는지 확인한다.

1:1 통신과 3 ways handshaking

상대에게 확실하게 데이터를 보냈는지 확인하기 위한 방법으로, 'SYN'과 'ACK' TCP flag를 사용한다.

 

step 1. 송신측에서 'SYN' 상태로 상대에게 접속함과 동시에 패킷을 보낸다.

step 2. 수신측에서는 'SYN/ACK' 플래그로 송신측에 접속함과 동시에 패킷을 수신한 사실을 전한다.

step 3. 송신측이 'ACK' 플래그를 보내 패킷 교환이 완료 된다.

 

 

*만약 어디선가 통신이 끊어진다면, TCP는 그와 동시에 같은 순서대로 패킷을 재전송 한다.

 

이름을 해결을 담당하는 DNS

DNS(Domain Name System)는 HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP주소 이름 확인을 제공한다.

 

---

HTTP 통신방법

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

HTTP 통신시 반드시 어느 한 쪽은 클라이언트가 되고 다른 한 쪽은 서버가 된다.

Request와 Response를 교환하여 성립한다.

반드시 클라이언트로 부터 Request 통신이 시작 되고, 서버 측은 request를 받지 않고서는 reponse를 송신하는 일은 없습니다.

 

         사진 출저:  https://subscription.packtpub.com/book/networking_and_servers/9781785887819/5/ch05lvl1sec35/http

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

• HTTP은 독자적으로 request와 response를 교환하는 동안의 상태를 관리하지 않는다. 
• 이전에 보냈던 requset, 이미 돌려준 reponse에 대해서도 전혀 관리되지 않는다.
• HTTP에서는 새로운 request가 보내질 때 마다 새로운 response가 생성된다.

장점 : 많은 data를 매우 빠르고 확실하게 처리하기 위해 간단하게 설계됨

단점:  특정 사이트 로그인시 다른 페이지를 이동해도 그 로그인 상태를 유지할 수 없다. -> 쿠키 기술 도입

 

 

 

쿠키(Cookie)

http 프로토콜의 주고받기에 관한 정보를 클라이언트측에 저장해 두고 다음 통신때 그 정보를 서버에게 제시하면 서버는 사용자를 지정하고, 잊너 회에서 이어진 통신으로 취급한다.

이때 주고 받는 정보를 쿠키 라고 한다.

 

쿠키는 일반 http 프로토콜의 정규 장치가 아니라 보통은 CGI(Common Gate way Interface)등 클라이언트로 부터 요청에 맞게 웹페이지를 작성하는 장치와 함께 사용한다.

 

http://mbsbears.com/teched/webdesign/kss/webdesign12/Webegineering/lec06.htm

 

쿠키에도 유효기간이 있어 기간이 지난 쿠키는 클리이언트에 의해 자동적으로 삭제된다. 유효기간 설정은 쿠키 제작자가 하지만, 설정을 하지 않은 경우에는 브러우저가 닫힐 때 로 제한합니다.

 

HTTP는 request URI로 리소스를 식별

HTTP는 URI(Uniform Resource Identifiers) 를 사용하여 인터넷 상의 리소스를 지정합니다. 이 URI가 있는 덕분에 인터넷 상의 어떤 장소에 있는 리소스도 호출 할 수 있다.

 

서버에 임무를 부여하는 HTTP 메소드

Get 메소드: 리소스 획득 (정보를 달라고 한다)

• Get 메소드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구한다.
• URI에 이어붙기 때문에 길이 제한이 있어서 많은 양의 데이터는 보내기 어렵다.
• 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과로,  텍스트이면 그대로 반환, 프로그램이면 실행해서 출력된 내용을 돌려준다.
• 성공시 status code가 200 OK
• get은 길이 제한이 있어서 10MB를 보내고 싶어도 리미터가 있어서 온전히 보낼 수 없어서 잘라서 보내야한다.

Post 메소드: 엔티티 전송 (정보를 알려준다)

• Post 메소드는 엔티티를 전송하기 위해서 사용된다.
• 대용량 데이터를 전송 -> 전송해야할 데이터를 HTTP의 Body에 길이 제한 없이 데이터를 전송
• GET으로도 엔티티를 전송할 수 있지만 자주 사용하지 않고 일반적으로 POST를 사용한다.
• POST는 GET과 기능이 비슷하지만 response에 의한 엔티티를 획득하는 것만이 목적은 아닙니다.
• 성공시 status code가 201 created
• body로 보냈을때의 장점 은닉화(캡슐화), format의 제한이 없다(text,json), 사이즈 제한이 없다.

GET 메소드 VS POST 메소드

• GET 메소드 : 주로 조회 할 때 사용한다. (게시글 조회, 웹페이지 조회)
• GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다.
• POST 메소드 : 서버상태나 데이터 변경시 사용 (게시글 쓰기, 삭제 : 서버의 무언가가 변경)
• POST로 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있습니다.
•  

https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/

GET과 POST의 차이

https://blog.outsider.ne.kr/312

GET과 POST의 차이 :: Outsider's Dev Story

 

Delete 메소드

정보 삭제 요청

 

PUT 메소드

정보 수정 요청

 

https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C

HTTP 상태 코드 - 위키백과, 우리 모두의 백과사전

---

HTTP 약점

• 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없 기 때문에 변조 가능

평문이기 때문에 도청 가능

HTTP를 사용한 request나 reponse 통신 내용은 HTTP 자신을 암호화 하는 기능이 없기 때문에 통신 전체가 암호화 되지는 않고 평문으로 HTTP를 보내게 된다.

TCP/IP는 도청 가능한 네트워크

TCP/IP의 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있기 때문에 HTTP도 보안에 취약하다.

(인터넷은 네트워크로 이뤄져있는데, 이 네트워크의 전부를 개개인이 소유할 수 없기 때문)

 

사진 출저 : https://www.wireshark.org/docs/wsug_html_chunked/ChapterWork.html

해결방법 : 암호화

• 통신암호화 : HTTP에 SSL이나 TLS라는 다른 프로토콜을 조합하여 HTTP 통신 애용을 암호화 하는 방법
• 콘텐츠 암호화 : HTTP 메세지에 통신하고 있는 콘텐츠의 내용 자체를 암호화 하는 방법

 

통신 상대를 확인하지 않아 위장 가능

HTTP를 사용한 request나 response에서는 통신 상대를 확인하지 않아 누구든지 request를 보낼 수 있고

request가 오면 웹 서버에 access 제한이 없다면 상대가 누구든지 무언가의 response를 반환한다.

(request를 보낸 서버가 정말 URI에 지정된 호스트여부, response를 반환한 client가 정말 request를 출력한 client인지 여부)

• request 보낸곳의 웹서버가 불명확
• response를 반환한 곳의 클라이언트가 불명확
• 통신하고 있는 상대의 접근 허가 불명확

해결 방법 : 증명서로 확인

HTTP로 통신 상대를 확인 할 수 없지만 SSL로 상대를 확인 할 수 있다.

SSL은 암호화 뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있기 때문에 이 증명서를 통해 상대가 신뢰할 수 있는지 아닌지를 판단할 수 있다.

 

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

HTTP는 전달과정에서 response나 request가 후 그 사이에 정보가 변조될 수 있기 때문에 정확한지 아닌지 확인을 할 수 없다. (수신한 내용이 다를 수 있다.)

 

해결 방법 : MD5, SHA-1 등의 해시 값을 확인하는 방법, 파일의 디지털 서명을 확인하는 방법

확실하면서도 편리한 방법은 없지만, 그 중 자주 사용되는 방식

---

HTTPS(HTTP Secure)

기존 HTTP의 통신의 경우 실제 사용시 아래와 같은 문제가 발생 할 수 있다.

• HTTP통신은 암호화 되지 않응 평문으로 실시 : 웹페이지에 신용 카드 번호 입력시 통신 도청되면, 카드 번호가 도청된다.
• 통신 상대의 서버나 클라이언트 인증하는 수단이 없다 : 메세지 변조 가능, 통신 상대의 불명확성

 

HTTPS에 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화 할 수 있다. => SSL 등을 이용해 안전한 통신로를 확립하고 그 통신로를 사용해 HTTP 통신을 하는 방식 

HTTPS 형태

HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라 HTTP 통신 소켓 부분을 SSL/TLS란 프로토콜로 대체할 뿐이다.

 

 

HTTPS의 경우, HTTP --> SSL --> TCP와 통신 방식으로, SSL/TLS는 HTTP와는 독립된 프로토콜로 HTTP만으로는 애플리케이션 계층에서 동작하는 SMTP, Telnet 등에서도 이용 될 수 있다.

 

공개키 암호화 방식

SSL에서는 공개키 암호화 방식을 채용하고 있다. 암호화나 복호화시 키를 사용하고 없을 경우 암호를 풀 수 없다.

다만, 암호화와 복호화에 하나의 키를 같이 사용할 경우 공격자에게 키를 빼앗기면 암호화의 의미가 없어버리게 된다.

이런 이유로 두개의 키를 사용하는 공개키 암호 방식을 사용한다.

 

• 두개의 키를 공개키: 서로 다른 두개의 키 페어(쌍)을 사용한다. 한쪽은 비밀키, 한쪽은 공개키라고 부른다.
• 발신자 : 수신자의 공개키로 암호화 하여 리소스 전달 -> 수신자 : 수신자의 비밀키로 복호화
• 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의한 문제 해결

문제점 : 공개키의 진위 여부

발신자가 리소스를 보낼때, 수신자의 공개키가 진짜인지 아닌지 증명 할 수 없다.

도중에 공격자가 공개키를 바꿔치기 할 수 있기 때문

 

해결방법 : 인증기관 공개키

인증기관 CA와 그 기관이 발행하는 공개키 증명서를 이용하여 확인한다.

단, 모두가 신뢰하는 기관이 아닌 곳의 증명서를 사용할 경우 보안에 문제가 생길 수 있다.

1. 서버 운경자가 CA에 공개키 제출
2. CA는 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키 생성
3. 공개키 인증서에 해당 공개키를 담는다.
4. 서버는 이 인증 기관에 의해 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신
5. 이 공개키 인증서(증명서)를 받은 클라이언트는 공개키를 신뢰할 수 있다.

SSL의 문제점 : 처리 속도가 늦다.

• CPU/메모리 등 리소스를 다량으로 소비

HTTPS 서버,클라이언트 모두 암호화와 복호화 처리가 필요하기 때문에 CPU나 메모리 등의 하드웨어 리소스를 소비한다.

• 통신 속도가 떨어진다.

SSL은 반드시 암호화 처리를 하고 있어 서버,클라이언트에서는 암호화나 복호화를 위한 계산을 할 필요가 있다.

-> 서버/클라이언트의 리소스를 소비하게 되어 HTTP에 비해 부담이 커진다.

 

항상 HTTPS를 사용하지 않는 이유

• 평문 통신에 비해 암호화 통신은 메모리/CPU 리소스가 많이 필요하기 때문에 민감한 정보가 없을 경우 HTTP를 사용 (특히 액세스가 많은 웹사이트의 경우 부하가 상당하다)
• 증명서 구입 비용 : CA에서 증명서를 구입시 비용 지불을 해야하기 때문

 

 

출저 : 그림으로 배우는 HTTP & Network basic , TCP/IP가 보이는 그림책

---

추가로 알아두면 좋은 개념들

REST API

SSL