[Network] 11. Web & HTTP


Web

  • World Wide Web 으로 WWWWeb으로 불리며, 인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간을 의미한다.
  • 특징으로 웹에서는 HTML 이라는 hypertext 언어를 사용하여 문서를 작성하고, HTTP 라는 프로토콜을 사용하여 검색하고 접근이 가능하다.

웹 브라우저 - 웹 서버 네트워크 요청 과정

Untitled

  • 1~2 : 사용자가 웹 브라우저를 통해 찾고 싶은 웹 페이지의 URL 주소를 입력한다.
  • 3 : 사용자가 입력한 URL 주소 중에서 도메인 네임 부분을 DNS 서버에서 검색한다.
  • 4 : DNS 서버에서 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달한다.
  • 5~6 : 웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 페이지를 생성하고, 이렇게 생성된 HTTP 요청 메세지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송한다.
  • 7 : 이렇게 도착한 HTTP 요청 메세지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송한다.
  • 8 : 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색한다.
  • 9~10 : 검색된 웹 페이지 데이터는 또 다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성하고, 이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송한다.
  • 11 : 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환한다.
  • 12 : 변환된 웹 페이지 데이터는 웹 브라우저에 의해 사용자에게 출력된다.

  • 구글을 통해 다시 이해해보자.

    Untitled

    1. 웹 브라우저는 www.google.com 의 실제 주소를 DNS 서버로 요청하게 되고, DNS 서버는 이를 IP 주소로 바꿔준다. IP 주소를 DNS 서버에 요청할 때 인터넷 탐색을 빠르게 만들기 위해 DNS 는 가장 가까운 서버의 IP 주소를 제공한다.
    2. 웹 브라우저가 웹 서버에 이 IP 주소로 80포트 또는 443포트에 IP 를 통한 TCP(Transmission Control Protocol)로 연결을 요청한다. IP 는 인터넷을 통해 트래픽을 보내는 데 사용되지만, TCP는 연결을 안정적으로 만드는 안정성과 재전송을 추가해준다.
    3. 브라우저가 웹 서버와 연결을 맺고 있으면 웹 사이트에 요청하기 시작할 수 있다. 이 단계에서 HTTP 가 관여한다.
    4. 구글 서버가 요청받은 URL 에 응답한다. 일반적으로 첫 페이지에서 돌려받는 것은 HTML 형식의 텍스트지만, 구글은 https 로만 운영되기 때문에 https://www.google.com 로 리디렉션하는 특수한 HTTP 명령을 반환한다. 뭔가 잘못된 경우에는 HTTP 응답 코드를 돌려받는데, 대표적인 코드가 404 Not Found 다.
    5. 웹 브라우저가 반환된 응답을 처리한다. HTML 을 받았다면 코드 해석을 시작하고 메모리에 해당 페이지의 내부 표현인 DOM (Document Object Model)을 구축한다.
    6. 웹 브라우저가 추가로 필요한 리소스를 요청한다. 구글의 경우 이 단계에서 16개의 리소스만 요청하는데, 이러한 리소스 각각이 1 ~ 6 단계를 따라 유사한 방식으로 요청된다.
    7. 브라우저가 중요한 리소스를 충분히 얻으면 화면에 페이지를 그리기 시작한다.
    8. 페이지를 처음 표시한 후 웹 브라우저는 백그라운드에서 페이지에 필요한 다른 리소스들을 계속 다운로드하고 처리하는 대로 페이지를 업데이트한다.
    9. 완전히 로드되면 브라우저는 로딩 아이콘을 멈추고, 자바스크립트 코드에서 페이지가 어떤 동작을 수행할 준비가 됐다는 표시로 사용할 수 있는 OnLoad 이벤트를 발생시킨다.
    10. 이후로도 계속 필요한 리소스를 요청하고 받는다. 페이스북 피드가 새로고침 버튼 없이도 업데이트 되는 걸 생각하면 이해하기 쉽다.

웹 브라우저 - 웹 서버 TCP/IP 통신 과정

Untitled

  • 애플리케이션을 실행시키는 웹 서버 컴퓨터와 웹 브라우저 컴퓨터는 각각 4개의 계층을 순차적으로 통과하면서 각각의 프로토콜에 따라 데이터를 처리한다.
  • 네트워크를 연결하여 인터넷을 만드는 중간 노드인 라우터는 네트워크 인터페이스 계층과 인터넷 계층의 프로토콜에 따라 데이터를 처리한다.
    1. 웹 서버의 데이터 송신

      Untitled

      • 웹 서버 애플리케이션은 웹 서비스를 제공하기 위해 웹 페이지(HTML)라는 데이터를 만든다.
      • 이후 응용 계층에서부터 네트워크 인터페이스 계층으로 갈수록 각 다음 계층으로 넘겨주기 위해 필요한 정보헤더(Header) 에 추가하여 넘겨주게 된다.
      • 마지막으로 이더넷 헤더를 추가한 데이터, 즉 이더넷 프레임은 전기 신호로 변환되어 전송 매체를 통해 인터넷으로 내보낸다.
    2. 라우터의 데이터 처리

      Untitled

      • 인터넷에서 데이터를 수신한 라우터네트워크 인터페이스 계층이더넷 헤더의 MAC 주소를 읽고 자기 앞으로 온 데이터가 맞는지 확인한다.
      • 만약 맞다면 데이터를 수신하고 이더넷 프레임에서 이더넷 헤더를 삭제한 데이터(IP 패킷)를 인터넷 계층으로 넘긴다.
      • 인터넷 계층은 IP 헤더의 IP 주소를 읽고 자기 앞으로 온 데이터가 맞는지 확인하는데, 이러한 경우 보통 라우팅이라는 라우터의 기능을 이용해 데이터를 전송할 라우터나 호스트를 조사한 뒤 데이터를 전송하게 된다.
    3. 웹 브라우저의 데이터 수신

      Untitled

      • 인터넷을 통해 웹 클라이언트에 도착한 전기 신호는 네트워크 인터페이스 계층에서 디지털 데이터로 변환된다.
      • 이 데이터는 다시 계층을 거치면서 헤더가 제거되고 결국 응용 계층에서 HTTP 헤더를 읽고 웹 서비스를 제공할 수 있도록 데이터를 처리하여 웹 브라우저에 웹 페이지를 보여준다.

웹의 구성요소

  • 프록시
    • 서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 요청(Request)를 서버에 전송하고, 서버로부터의 응답(Response)을 클라이언트에 전송한다.
    • 캐싱 프록시투명 프록시 2가지가 있다.
      • 캐싱 프록시 : 프록시에 다시 같은 리소스의 요청이 온 경우, 오리진 서버로부터 리소스를 휙득하는 것이 아니라 캐시를 응답으로서 되돌려 주는 타입의 프록시
      • 투명 프록시 : 요청과 응답을 중계할 때 메시지 변경을 하지 않는 타입의 프록시
  • 캐시
    • 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킨다.
    • 리소스를 가진 서버에 엑세스를 줄이는 역할을 하고, 통신량과 통신 시간을 절약할 수 있다.
  • 게이트웨이
    • 클라이언트 $\leftarrow$ HTTP $\rightarrow$ 게이트웨이 $\leftarrow$ HTTP 이외의 통신 $\rightarrow$ HTTP 이외의 서버
    • 프로토콜이 다른 네트워크 상의 컴퓨터와 통신하기 위해 두 프로토콜을 적절히 변환해 주는 변환기이다.
  • 터널
    • 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램
    • HTTP 요청을 해석하지 않고, 요청 그대로 서버에 중계한다.
    • SSL 과 같은 암호화 통신

쿠키와 세션

  • 쿠키와 세션은 HTTP 프로토콜의 특징인 Connectionless 와 Stateless 의 약점을 보완하기 위해서 사용된다.
  • 쿠키와 세션은 비슷한 역할을 하며 동작원리도 비슷하지만, 가장 큰 차이점은 사용자의 정보가 저장되는 위치이다.
  • 쿠키
    • HTTP 의 일종으로 사용자가 어떤 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.
    • 쿠키의 특징
      • 이름, 값, 만료일, 경로 정보로 구성되어 있다.
      • 클라이언트에 총 300개의 쿠키를 저장할 수 있고, 하나의 도메인 당 20개의 쿠키를 가진다.
      • 하나의 쿠키는 4KB까지 저장 가능하다.
    • 쿠키의 동작 순서
      1. 클라이언트가 페이지를 요청하면 웹 서버는 쿠키를 생성한다.
      2. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
      3. 넘겨받은 쿠키는 클라이언트가 가지고 있다가 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
      4. 동일 사이트 재방문 시 클라이언트의 PC 에 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.
    • 쿠키 사용 예시
      • 방문 사이트에서 로그인 시, “아이디와 비밀번호를 저장하시겠습니까?
      • 팝업창을 통해 “오늘 이 창을 다시 보지 않기” 체크
  • 세션
    • 일정 시간 동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술
    • 일정 시간의 의미는 방문자가 웹 서버에 접속한 시점에서 웹 브라우저 종료하는 시점을 의미한다.
    • 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 세션이라 표현한다.
    • 세션의 특징
      • 웹 서버에 웹 컨터이너의 상태를 유지하기 위한 정보를 저장한다.
      • 브라우저를 닫거나 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
      • 저장 데이터에 제한이 없다.
      • 각 클라이언트에 고유 ID를 부여하고, ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공한다.
    • 세션의 동작 순서
      1. 사용자가 웹사이트에 접근하면 서버는 클라이언트의 Request-Header 필드인 Cookie 를 확인하여 클라이언트가 해당 session-id 를 보냈는지 확인한다.
      2. session-id 가 없을 경우 생성해서 클라이언트에게 돌려준다.
      3. 서버에서 돌려준 session-id 를 쿠키를 사용해 서버에 저장한다.
      4. 클라이언트는 재접속 시 이 쿠키를 이용해 session-id 값을 서버에 전달한다.
    • 사용 예시
      • 화면을 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지되는 현상

HTTP

  • Hyper Text Transfer Protocol 의 약자로, 웹 상에서 정보를 주고 받을 수 있는 프로토콜이다.
  • 또한 HTTP 는 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜이다.

    Untitled

  • HTTP 1.0
    • 브라우저 친화적인 프로토콜
    • 요청 및 응답에 대한 메타 데이터를 포함하는 헤더 필드 제공한다.
    • Response : Content-Type 에 HTTP 파일 외에도 스크립트, 스타일 시트, 미디어 등을 전송할 수 있다.
    • Method : Get, Head, Post
    • Connection 특성 : 응답 직후 종료 Closed
    • 단점 : 각 모든 요청에 따라 새로운 연결을 열고, 응답이 전송된 후 즉시 닫기 때문에 새로운 연결이 설정 될 때마다 TCP 3-way Handshake 가 발생한다.
  • HTTP 1.1
    • 오늘날 가장 많이 사용되는 HTTP 버전
    • 영구 및 파이프 라인 연결, 압축/압축 해제, 가상 호스팅, 캐시 등이 추가되어 응답속도가 빨라지고 대역폭이 절약되는 등 성능 최적화 및 기능 향상
    • Method : Get, Head, Post, Put, Delete, Trace, Options
    • Connection 특성 : long-lived
    • HTTP 1.0의 단점을 보완하기 위해 Connection 특성을 변경하여 만들어진 HTTP 프로토콜이다.
  • HTTP 2.0
    • HTTP 1.1 프로토콜을 계승해 동일한 API 면서 성능 향상에 초점을 맞춘 프로토콜
    • 구성된 연결 내에서 전달되는 바이트의 양방향 흐름, 하나 이상의 메시지가 전달 가능하다.(Stream)
    • 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스이다.
    • 통신의 최소 단위로 Frame 을 사용하고, 하나의 프레임에는 하나의 프라임 헤더가 포함된다.
    • Multiplexed Stream
    • 한 Connection 으로 동시에 여러 개 메시지를 주고 받을 수 있으며, Response 는 순서에 상관 없이 stream 으로 주고 받는다.
    • 클라이언트가 요청하기 전에 필요하다고 예상되는 리소스를 Server 에서 먼저 요청한다.
    • Header table 과 Huffman Encoding 기법을 이용해 압축했다.
    • 이전 헤더의 내용과 중복되는 필드를 재전송하지 않아 데이터를 절약한다.
  • HTTPS
    • Hyper Text Transfer Protocol Secure 의 약자로, HTTP 에 데이터 암호화가 추가된 프로토콜이다.
    • 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.
  • SSL vs TLS
    • SSL 과 TLS 는 네트워크를 통해 작동하는 서버, 시스템 및 응용프로그램 간에 인증 및 데이터 암호화를 제공하는 암호화 프로토콜이다.
    • TLS 는 SSL 의 취약성을 해결하고 더 강력하고 안전한 암호화 제품군 및 알고리즘을 지원하기 위해 새로운 버전의 프로토콜로 출시되었다.
    • SSL/TLS 를 사용하는 웹사이트 URL 은 HTTP 대신 HTTPS 가 사용된다.
    • 작동방식
      • SSL 은 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화 한다. 따라서, 데이터를 가로채려 해도 거의 복호화가 불가능하다.
      • SSL 은 클라이언트와 서버 간에 Handshake 를 통해 인증이 이루어진다. 또한 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인한다.
      • Handshake 는 클라이언트와 서버 간의 메세지 교환이며, HTTPS 웹에 처음 커넥션할 때 진행된다.
      • Handshake 의 단계는 클라이언트와 서버에서 지원하는 암호화 알고리즘, 키 교환 알고리즘에 따라 달라진다. 일반적으로는 RSA 키 교환 알고리즘이 사용된다.
    • SSL 은 SSL 인증서(=TLS 인증서)가 있는 웹사이트만 실행할 수 있다. 인증서는 사람의 신분증과 유사하다고 볼 수 있다.
    • SSL 인증서에는 공개 키가 포함된다. 이 공개키 덕분에 암호화가 가능하게 된다. 클라이언트의 요청은 공개 키를 이용해 서버에 암호화 하여 전달한다.
    • 서버에도 공개되지 않는 개인 키가 있는데 이 개인 키를 이용해 암호화된 데이터를 복호화한다. 해당 인증서를 발급하는 기관은 CA(certificate authority)라고 한다.
  • 대칭키와 비대칭키
    • 둘 다 HTTP 에서 사용되는 암호화 방식이다.
      • 대칭키 암호화
        • 클라이언트와 서버가 동일한 키를 사용해 암호화를 진행한다.
        • 키가 노출되면 매우 위험하지만 연산 속도가 빠르다.
      • 비대칭키 암호화
        • 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용한다.
        • 키가 노출되어도 비교적 안전하지만 연산 속도가 느리다.
맨 위로 이동 ↑

댓글 남기기