공부하는개미

🔗 참고자료

• [성공과 실패를 결정하는 1% 의 네트워크 원리] 책 챕터 05

✍ 공부하게 된 계기

부트캠프를 진행하면서 WAS의 부하를 분산하기 위해 DB서버, 웹서버, 캐시서버를 나눠서 환경을 구축했었다.

이 부분에서 가장 신기했던 것은 캐시서버 환경을 구축하는 것이였다. 비록 WAS에 캐시를 Redis 환경을 직접 구축하기는 했지만, 클라이언트들이 자주 방문하는  첫 페이지의 데이터를 빠르게 조회 할 수 있었다.

고맙게도 [성공과 실패를 결정하는 1%의 네트워크 원리]에 이 내용에 대해 자세히 나와있었다.

그때의 기억을 살리면서 글로 적고 공부를 하려고 한다.

1. 캐시 서버의 이용

• 여러 대의 웹 서버를 설치하는, 즉 같은 기능을 가진 여러 대의 서버를 설치하는 것이 아니라
  데이터베이스 서버와 웨베 서버 같은 역할에 따라 나누는 방법이다.
  이러한 역할별 분산 처리 방법 중의 하나가 캐시 서버를 사용하는 방법이다.
• 캐시 서버는 프록시라는 구조를 사용하여 데이터를 캐시에 저장하는 서버이다.
• 프록시는 웹 서버와 클라이언트 사이에 들어가서 웹 서버에 대한 액세스 동작을 중개하는 역할을 한다.
• 액세스 동작을 중개할 때 웹 서버에서 받은 데이터를 디스크에 저장해 두고 웹 서버를 대신하여 데이터를 클라이언트에 반송하는 기능을 가지고 있다. 이것을 캐시라고 부른다.

캐시(cache) 서버를 사용하는 이유

• 웹 서버는 URL을 점검, 액세스 권한 점검, 페이지 안에 데이터를 내장하는 등의 처리를 내부에서 실행하기 위해 페이지의 데이터를 클라이언트에 송신할 때 다소 시간이 걸린다.
  한편 캐시 서버쪽은 웹 서버에서 받아 보존해 둔 데이터를 읽어서 클라이언트에 송신만 하므로 웹 서버보다  빨리 데이터를 송신할 수 있다.

캐시 서버의 장, 단점

• 단점
  - 캐시에 데이터를 저장한 후 웹 서버측에서 데이터가 변경되면 캐시의 데이터를 사용할 수 없습니다.
  따라서 언제든지 캐시의 데이터를 이용할 수 있는 것은 아닙니다.
  - CGI 애플리케이션 등이 출력하는 페이지 데이터도 내용이 매번 달라지므로 캐시를 이용할 수 없습니다.
• 장점
  - 액세스 동작의 일정부분은 웹 서버를 번거롭게 하지 않고 캐시 서버에서 처리할 수 있습니다.
  얼마라도 캐시 서버에서 액세스 동작을 고속화 할 수 있으면 전체 성능이 향상된다고 생각하는 것입니다.
  - 캐시 서버에서 리퀘스트를 처리하면 그만큼 웹 서버의 부하가 줄면서 웹 서버의 처리 시간을 단축할 수 있습니다.

2. 포워드 프록시

• 클라이언트측에 캐시 서버를 두는 방법.
• 프록시라는 구조는 원래 클라이언트측에 두는 방법에서 시작되었다.
• 캐시를 이용한다는 목적 외에도 방화벽을 실현한다는 중요한 목적도 있었다.
  - 프록시에서 리퀘스트 메시지를 일단 받아서 인터넷을 향해 전송하면 필요한 것을 통과시킬 수 있다는 개념이다.
  - 프록시는 리퀘스트의 내용을 조사한 후 전송하므로 리퀘스트의 내용에 따라 액세스가 가능한지 판단할 수 있다.
  즉 위험한 사이트나 작업과 관계 없는 사이트에 대한 액세스는 금지한다는 액세스 제한을 마련할 수 있다.
• 브라우저에 대한 설정이 꼭 필요합니다.
  - 브라우저의 설정이 번거롭고 잘못 설정할 경우에는 브라우저가 제대로 작동하지 않는 장애의 원인이 되기도 합니다.

3. 리버스 프록시

• 브라우저에 프록시를 설정하지 않아도 사용할 수 있도록 한 것.
  - 즉 리퀘스트 메시지의 URI에 쓰여있는 디렉토리명과 전송 대상의 웹 서버를 대응시켜서 URI 부분에 http://...라고
  쓰여있지 않은 보통의 리퀘스트 메시지를 전송할 수 있도록 했다.
• 서버측에 설치하는 캐시 서버

4. 트랜스페어런트 프록시

• 캐시 서버에서 전송 대상을 판단하는 방법, 즉 리퀘스트 메시지에서 패킷의 헤더를 조사하는 방법이다.
• 패킷의 맨 앞에 있는 IP 헤더에는 수신처 IP 주소가 기록되어 있으므로 이것을 조사하면 액세스 대상 웹 서버가 어디에 있는지 알 수 잇다.
• 보통의 리퀘스트 메시지를 전송할 수 있으므로 포워드 프록시처럼 브라우저에 설정할 필요가 없다.
• 전송 대상을 캐시 서버에 설정할 필요도 없고, 어느 웹 서버에서나 전송할 수 있다.
• 포워드 프록시와 리버스 프록시의 좋은 점만 모은 형태의 편리한 구조

📚 참고자료

• 티스토리 블로그 [Untitled] 웹 스토리지(Web Storage)의 특성과 사용법 => 링크​
• 벨로그 [hellozin] 쿠키, 세션 그리고 웹 스토리지 => 링크

* 공부 목적으로 위 참고자료를 보고 정리한 글입니다.

🍪 쿠키란?

쿠키는 클라이언트 로컬에 저장되는 키와 값 형태의 작은 파일로 이름, 값, 만료 시간, 경로 정보가 들어있습니다.

쿠키는 주로 세 가지 목적을 위해 사용됩니다.

• 세션 관리: 서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리
• 사용자 맞춤: 사용자가 선호하는 옵션이나 테마 등의 세팅
• 사용자 추적: 사용자의 행동을 기록하고 분석하는 용도

'Response Header' 의 'Set-Cookie' 속성을 사용하면 클라이언트에 쿠키를 만들 수 있으며 만들어진 쿠키는 클라이언트가

따로 설정하지 않아도 브라우저가 Request Header에 넣어서 서버로 전송하게 됩니다.

서버의 HTTP 응답 헤더에서 쿠키를 설정합니다.

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: name=ant
Set-Cookie: age=2

이 후 클라이언트에서 보내는 모든 요청에 브라우저는 Cookie 헤더를 통해 저장된 모든 쿠키를 전송합니다.

Get /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: name=ant; age=2

이렇게 만들어진 쿠키는 스코프에 의해 크게 두가지로 나눌 수 있습니다.

• 클라이언트가 종료되면 삭제되는 휘발성 쿠키 => Session Cookie
• 클라이언트가 종료되어도 일정 기간 유지되는 쿠키 =>  Permanent Cookie

Permanent Cookie는 Expires(날짜와 시간) 혹은 Max-Age(초) 를 명시해 해당 날짜, 혹은 시간까지 쿠키를 유지할 수 있고

아무것도 명시하지 않을 경우 Session Cookie 가 됩니다.

Set-Cookie: name=ant; Expires=wed, 21 oct 2022 08:20:00 GMT;

💾 웹  스토리지란?

웹 스토리지(Web storage)는 서버가 아닌, 클라이언트에 데이터를 저장할 수 있도록 지원하는 HTML5의 새로운 기능이다.

웹 스토리지와 쿠키의 기능 자체는 유사하지만, 쿠키는 약 4KB까지 밖에 저장 공간을 이용하지 못하는 반면에 웹스토리지는 약 5MB까지

저장 공간을 이용할 수 있다.

웹 스토리지에는 로컬 스토리지 (local Storage)와 세션 스토리지 (session Storage)가 있다. 로컬 스토리지와 세션 스토리지는 각각의 고유한 특성이 있으며, 프로그래머의 필요에 따라 선택적으로 사용된다.

1. 로컬 스토리지 (Local Storage)

로컬 스토리지는 브라우저에 반영구적으로 데이터를 저장하며, 브라우저를 종료해도 데이터가 유지된다.

브라우저 자체에 반영구적으로 데이터가 유지되지만, 도메인(domain)이 다른 경우에는 로컬 스토리지에 접근할 수 없다.

2. 세션 스토리지(Session Storage)

세션 스토리지는 각 세션마다 데이터가 개별적으로 저장된다. 예를 들어, 브라우저에서 여러개의 탭을 실행하면 탭마다 개별적으로 데이터가 저장되는 것이다. 세션 스토리지는 로컬 스토리지와 다르게 세션을 종료하면 데이터가 자동으로 제거되며, 같은 도메인이라도 세션이 다르면 데이터에 접근할 수 없다.

면접에서 세션과 쿠키에 대한 질문을 여러번 받았습니다.

하지만 제대로 답하지 못했었습니다.

웹 프로그래밍을 배우면서 초반에 나온 개념이지만 제대로 안보고 그냥 넘어갔다는 것을 알게되어  이렇게 블로그에 적어봤습니다.

알게된 점

• 웹 스토리 API는 기존 쿠키의 문제점을 극복하기 위해 웹 브라우저가 직접 데이터를 저장할 수 있게 해줬다.
• 세션을 물어본건 결국 웹 스토리지에 대한 개념을 물어본 것
• 쿠키는 클라이언트와 서버가 서로 주고 받을 수 있다.
• 쿠키는 유효기간을 설정 할 수 있다(Expire)
• 도메인에 대한 지식을 알아야겠다고 생각했습니다.

참고자료

• 블로그 [gmlwjd9405] Web Server와 WAS의 차이와 웹 서비스 구조 => 링크
• 블로그 [코드사냥꾼] 웹 서버와 WAS의 차이를 쉽게 알아보자 => 링크
•  

1️⃣ 정적 페이지(Static Pages)와 동적 페이지(Dynamic Pages)

1. 정적 페이지(Static Pages)

• Web Server는 파일 경로 이름을 받아 경로와 일치하는 file contents를 반환한다.
• 항상 동일한 페이지를 반환한다.
• 단순 HTML 문서, CSS, JavaScript, 이미지, 파일 등 즉시 응답 가능한 컨텐츠이다.
• 사전적 정의
  웹 브라우저 클라이언트로부터 HTTP 요청을 받아들이고 HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램

2. 동적 페이지(Dynamic Pages)

• 인자의 내용에 맞게 동적인 contents를 반환한다.
• 즉, 웹 서버에 의해서 실행되는 프로그램을 통해서 만들어진 결과물 * Servlet: WAS위에서 돌아가는 Java Program
• 개발자는 Servlet에 doGet()을 구현한다.

2️⃣ Web Server와 WAS의 차이

# 웹서버(Web Server)

웹서버의 개념

소프트웨어와 하드웨어로 구분된다.

• 하드웨어 
  => Web 서버가 설치되어 있는 컴퓨터
• 소프트웨어
  => 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를
  제공하는 컴퓨터 프로그램

웹서버의 기능

• HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스하는 기능을 담당한다.
• 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행한다.
  기능 1)
  - 정적인 컨텐츠 제공
  - WAS를 거치지 않고 바로 자원을 제공한다.
  
  기능 2)
  - 동적인 컨텐츠 제공을 위한 요청 전달
  - 클라이언트 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
  - 클라이언트는 일반적으로 웹 브라우저를 의미한다.

웹서버의 예

=> Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등

# WAS(Web Application Server)

WAS의 개념

• 사전적 정의
  인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서,
  주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행
• DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server
• HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.
• "웹 컨테이너(Web Container)" 혹은 서블릿 컨테이너(Servlet Container)"라고도 불린다.
  • Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다.
  • 즉, WAS는 JSP, Servlet 구동 환경을 제공한다.

WAS의 역할

• WAS = Web Server + Web Container
• Web Server 기능들을 구조적으로 분리하여 처리하고자 하는 목적으로 제시되었다.
  • 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
  • 주로 DB 서버와 같이 수행된다.
• 현재는 WAS가 가지고 있는 Web Server도 정적인 컨텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.

WAS의 주요 기능

• 프로그램 실행 환경과 DB 접속 기능 제공
• 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능
• 업무를 처리하는 비즈니스 로직 수행

WAS의 예

=> Tomcat, JBoss, Jeus, Web Sphere 등

3️⃣ Web Server가 필요한 이유

클라이언트(웹 브라우저)에 이미지 파일(정적 컨텐츠)을 보내는 과정을 생각해보자.

• 이미지 파일과 같은 정적인 파일들은 웹 문서(HTML 문서)가 클라이언트로 보내질 때 함께 가는 것이 아니다.
• 클라이언트는 HTML 문서를 먼저 받고 그에 맞게 필요한 이미지 파일들을 다시 서버로 요청하면
  그때서야 이미지 파일을 받아온다.
• Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.

WAS가 정적 컨텐츠 요청까지 처리하면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고 이로
인해 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어진다.

따라서 Web Server에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.

4️⃣ WAS가 필요한 이유

웹 페이지는 정적 컨텐츠와 동적 켄텐츠가 모두 존재한다.
사용자의 요청에 맞게 적절한 동적 컨텐츠를 만들어서 제공해야 한다.
이때, Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결괏값을 모두 미리 만들어 놓고
서비스를 해야 한다. 하지만 이렇게 수행하기에는 자원이 절대적으로 부족하다.
따라서 WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때그때 결과를
만들어서 제공함으로써 자원을 효율적으로 사용할 수 있다.

5️⃣ Tomcat과 Apachge Tomcat

정적 컨텐츠를 처리하는 웹 서버에는 Apach가 있고, 동적 컨텐츠를 처리하는 WAS서버는 Tomcat이 있다.

그런데 Tomcat은 Apache Tomcat이라는 이름으로 많이 사용되어 혼란스러울 수 있다.

붙여서 쓰는 이유는 2008년에 릴리즈 된 Tomcat  5.5 버전부터 정적 컨텐츠를 처리하는 기능이 추가되었는데,

이 기능이 순수 Apache를 사용하는 것에 비해 성능적 차이가 전혀 없으며 Tomcat이 Apache의 기능을 포함하고

있기 때문에 Apache Tomcat이라고 부르고 있다.

참고자료

• 그림으로 배우는 Http & Network Basic 62 ~ 64페이지

 HTTP 메시지 

• HTTP에서 교환하는 정보는 HTTP 메시지라고 불리는데 Request 메시지와 Response 메시지가 있습니다.
• 복수 행(개행 문자는 CR+LF)의 데이터로 구성된 텍스트 문자열입니다.
• 크게 구분하면 메시지 헤더와 메시지 바디로 구성되고,
  최초에 나타나는 개행 문자(CR+LF)로 메시지 헤더와 메시지 바디를 구분합니다.
  * 이 안에 메시지 바디가 항상 존재한다고는 할 수 없습니다.

[ 메시지 헤더 ]

• 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성 등

[CR+LF]

• CR(carriage return) : 16진수 0x0d)와
  LF(line teed : 16진수 0x0a)

[메시지 바디]

• 꼭 전송되는 데이터 그 자체

 리퀘스트, 리스폰스 메시지의 구조 

◽ 리퀘스트 라인

리퀘스트에 사용하는 메소드와 리퀘스트 URI와 사용하는 HTTP 버전이 포함됩니다.

◽ 상태 라인

리스폰스 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전이 포함됩니다.

◽ 헤더 필드

리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포합됩니다.

일반 헤더필드, 리퀘스트 헤더 필드, 리스폰스 헤더 필드, 엔티티 헤더필드 등 4종류가 있습니다.

참고자료

• 그림으로 배우는 Http & Network Basic

네트워크의 기본은 TCP/IP

• 인터넷을 포함하여 일반적으로 사용하고 있는 네트워크는 TCP/IP라는 프로토콜에서 움직이고 있습니다.
  => HTTP는 그중 하나
  * 참고한 자료(책)에는 HTTP를 이해하기 위한 배경지식 정도로 TCP/IP를 다루고 있습니다.

 TCP/IP는 프로토콜의 집합

• 컴퓨터와 네트워크 기기가 상호간에 통신하기 위해서는 서로 같은 방법으로 통신하지 않으면 안됩니다.
  => 어떻게 상태를 찾고, 어떻게 상대에게 이야기를 시작하고, 어떠한 언어로 이야기를 하며,
        어떻게 이야기를 종료할까와 같은 규칙을 결정할 필요가 있습니다.
• 서로 다른 하드웨어와 운영체제 등을 가지고 서로 통신을 하기 위해서는 모든 요소에 규칙이 필요합니다.
  => 이러한 규칙을 프로토콜이라고 부릅니다.
• 인터넷과 관련되 프로토콜을 모은 것을 TCP/IP라고 부릅니다.

계층으로 관리하는 TCP/IP

• TCP/IP에서 중요한 개념 중 하나는 계층(Layer)입니다.
  => '애플리케이션 계층', '트랜스포트 계층', '네트워크 계층', '링크 계층' 총 4계층

계층으로 관리하는 이유

• 인터넷이 하나의 프로토콜로 되어 있다면 어디선가 사양이 변경되었을 때 전체를 바꾸지 않으면 안되지만,
  계층화되어 있으면 사양이 변경된 해당 계층만 바꾸면 됩니다.
• 각 계층은 계층이 연결되어 있는 부분만 결정되어 있어, 각 계층의 내부는 자유롭게 설계할 수 있습니다.
• 계층화하면 설계를 편하게 할 수 있습니다.
  => 애플리케이션 층에서 애플리케이션은 자기 자신이 담당하는 부분을 고려하면 되고, 상대가 어디에 있는지,
       어떠한 루트로 전달하는지, 전달한 메시지가 확실하게 전달되고 있는지 고려를 하지 않아도 됩니다.

1. 애플리케이션 계층
   - 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정합니다.
   - FTP, DNS, HTTP도 이 계층에 포함됩니다.
2. 트랜스포트 계층
   - 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공합니다.
   - 서로 다른 성질을 가진 TCP(Transmission Control Protocol)와 UDP(User Data Protocol) 두 가지가 포함됩니다.
3. 네트워크 계층(혹은 인터넷 계층)
   - 네트워크 상에서 패킷의 이동을 다룹니다.
      * 패킷이란 전송하는 데이터의 최소 단위입니다.
   - 이 계층에서는 어떠한 경로(이른바 절차)을 거쳐 상대의 컴퓨터까지 패킷을 보낼지를 결정하기도 합니다.
   - 인터넷의 경우라면 상대 컴퓨터에 도달하는 동안 여러 대의 컴퓨터랑 네트워크 기기를 거쳐 상대방에 배송됩니다.
      그러한 여러 가지 선택지 중에서 하나의 길을 결정하는 것이 네트워크 계층의 역할입니다.
4. 링크 계층(혹은 데이터 링크 계층, 네트워크 인터페이스 계층)
   - 네트워크에 접속하는 하드웨어적인 면을 다룹니다.
     => 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버랑 네트워크 인터페이스 카드(NIC)를 포함합니다.
   - 하드웨어적 측면은 모두 링크 계층의 역합니다.

TCP/IP 통신의 흐름

TCP/IP로 통신을 할 때 계층을 순서대로 거쳐 상대와 통신을 합니다.

송신하는 측은 애플리케이션 계층에서부터 내려가고, 수신하는 측은 애플리케이션 계층으로 올라갑니다.

참고자료

• [MDN Web Docs] 교차 출처 리소스 공유(CORS)
• 블로그 [Evans Library] => CORS는 왜 이렇게 우리를 힘들게 하는 걸까?
• 우아한Tech 테코톡 => 나봄의 CORS

# SOP

• SOP는 Same Origin Policy의 줄임말
• 다른 출처의 리소스를 사용하는 것에 제한하는 보안 방식
  => 해커가 다른 출처의 리소스로 요청을 한다면, Cross Origin(다른 출처)라고 판단하고 요청을 거부한다.

# 출처(Origin)란?

• 서버의 위치를 의미하는 https://google.com과 같은 URL 들은 마치 하나의 문자열 같아 보여도,
  사실은 여러 개의 구성 요소로 이루어져 있다.
  즉, 서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐놓은 것이다.
• URL의 Protocl, Host, Port를 통해 같은 출처인지 다른 출처인지 판단할 수 있다.
  => Protocol, Host, Port 무엇이라도 다르면, 다른 출처라고 판단한다.
• 출처 내의 포트 번호는 생략이 가능한데, 이는 각 웹에서 사용하는 HTTP, HTTPS 프로토콜의 기본 포트 번호가
  정해져 있기 때문이다.

http://localhost와 동일 출처인 url은 무엇일까요?(더보기 클릭)

그렇다면 다른 출처의 리소스가 필요하다면 어떻게 할까?
=> 이때 필요한 게 CORS이다.

# CORS란?

• Cross-Origin Resource Sharing의 줄임말이다.
  => 다른 출처의 자원을 공유하는 것

교차 출처 리소스 공유(CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이

다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다.

참고자료

• 그림으로 배우는 Http & Network Basic

# HTTP의 약점

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

* 이 약점은 HTTP만이 아닌, 다른 암호화하지 않은 프로토콜에도 공통되는 문제입니다.

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

• 암호화되어 있지 않은 통신의 약점이 있는 이유는, TCP/IP 구조의 통신 내용은 전부 통신 경로의
  도중에 엿볼 수 있기 때문입니다.
  
  
• 암호화된 통신 내용도 엿볼 수 있다.
  => 네트워크 상을 흐르고 있는 패킷을 수집해서 도청 가능
  => 패킷 캡처인 [Wireshark]라는 툴을 사용하면 HTTP 리퀘스트 리스폰스 내용 취득 가능

위 이유 때문에 도청을 막기 보다는 암호화로 정보를 지키는 방법을 사용하고 있습니다.

# 통신 암호화

HTTP에는 암호화 구조가 없지만, SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)이라는

다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있습니다.

SSL을 조합한 HTTP를 HTTPS (HTTP Secure)라고 부릅니다.

# 상대를 확인하는 증명서

• HTTP에서는 통신 상대를 확인할 수 없다.
  => SSL로 상대를 확인할 수 있다.
  => 상대를 확인하는 수단으로 증명서를 제공하고 있습니다.
• 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되고 있습니다.
  그리고 그 증명서를 위조하는 것은 기술적으로 상당히 어렵습니다.

# HTTPS는 SSL의 껍질을 덮어쓴 HTTP

HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아닙니다.

HTTP 통신을 하는 소켓 부분을 SSL이나 TLS이라는 프로토콜로 대체하고 있을 뿐입니다.

보통 HTTP는 직접 TCP와 통신하지만 SSL을 사용한 경우에는 HTTP는 SSL와 통신하고 SSL이 TCP와 통신하게 됩니다.

즉 SSL이라는 껍집을 덮어 쓴 HTTP가 HTTPS인 것입니다.

• SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서, 완전성 보호를 이용할 수 있습니다.
• SSL은 HTTP와는 독립된 프로토콜입니다.
• 세계 어느 곳에서도 널리 사용되고 있는 네트워크 보안 기술입니다.

그러면 "전부 HTTPS로 하면 좋지 않을까?" 라는 생각을 할 수 있습니다.

# 왜 항상 HTTPS를 사용하지 않을까?

그 이유 중 하나는 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스가 많이 필요하기 때문입니다.

통신할 때마다 암호화를 하면 많은 리소스를 소비하게 됩니다.

그 결과 한건당 처리할 수 있는 리퀘스트의 수가 줄어들게 됩니다.

그래서 민감한 정보를 포함하지 않는 통신에는 HTTP를 사용하고,

개인 정보 등 민감한 정보를 다룰 때만 HTTPS를 사용합니다.

나머지 하나는 HTTPS를 사용하기 위해 CA에서 증명서를 구입해야 하기 때문입니다.

결론적으로 기업측에서 비용 부담이 들어 효율적으로 필요한 부분만 HTTPS를 사용합니다.

HTTP란?(클릭 시 링크로 이동)

클라이언트(Client) 와 서버(Server) 사이에 이루어지는 요청(Request) 와 응답(Response) 프로토콜(Protocol).

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜.

HTTP의 핵심은 요청(Request)과 응답(Response)이다.

* 대표적으로 HTML을 주고 받는다.

HTTP를 알기 위해 선행 되어야 할 것들

* 클릭 시 링크로 이동

• 클라이언트(Client)와 서버(Server)의 관계
• HTML이란?

URL(Uniform Resource Locators)

 서버에 자원을 요청하기 위해 입력하는 영문 주소

요청(Request)이란?

프론트엔드(클라이언트) 에서 백엔드(서버)에 보내는 메시지.

요청 메소드(Request Method)

• GET:  데이터를 서버로부터 받아올 때
• POST: 데이터를 생성, 수정할 때
• PUT:  존재하는 자원에 대한 변경
• DELETE: 존재하는 자원에 대한 삭제 메소드

응답(Response)란?

요청과 동일하게 서버가 클라이언트에 보내는 메시지.

HTTP 상태 코드(Response Status Codes)

참고자료

생활코딩[HTTP]

MDN 모질라[HTTP 개요]

캡틴판교

GET과 POST의 차이에 대해 잘 나와있는 영상을 아래 글에 추천합니다.

그리고 그 내용을 토대로 정리한 내용을 맨 마지막에 적었습니다.

www.youtube.com/watch?v=ts3eGy0-SOo

위 영상은 이고잉님이 무료로 올리신 강의입니다.

높은 퀄리티의 영상으로 많은 분들이 영상을 시청한 검증된 것입니다.

출처: opentutorials.org/course/1

GET의 특징

• 어떠한 정보를 서버로 전달할 때 URL뒤에 '?'를 붙이고, 그 안에 데이터를 적어 서버 쪽에 전송
• URL상에 서버로 전달하는 데이터가 포함되어 있다.
• 전송할 수 있는 정보의 길이가 제한되어 있다(브라우저마다 제한이 있다).
• 퍼머링크로 사용될 수 있다.

* 퍼머링크(permalink): 인터넷에서 특정 페이지에 영구적으로 할당된 URL 주소를 뜻한다. (출처: 위키백과)

POST의 특징

• URL에 데이터를 적지 않고 서버쪽으로 데이터 전송
• 전송할 수 잇는 데이터의 길이 제한이 없다.
• GET에 비해 보안상 약간의 우위에 있다.(사실상 동일)
• 퍼머링크로 사용할 수 없다.
• 서버 쪽에 어떤 작업을 명령할 때 사용한다. (데이터 기록, 삭제 수정 등)

위의 강의는 HTML 폼(form) 태그를 예시로 해서 설명한 영상입니다.

좀 더 심화된 내용은

opentutorials.org/course/62/5125

위 링크를 통해서 얻으 실 수 있습니다.