[Computer Science] 6주차 스터디 - HTTP와 HTTPS, URI와 URL과 URN, 포트와 소켓

HTTP와 HTTPS

• HTTP

  • HypterText Transfer Protocal

  • 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약

  • 80번포트를 사용함. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며 클라이언트는 80번 포트로 요청을 보내게 됨.

  • 팀 버너스 리에 의해 처음 설계

  • WWW 기반에서 세계적인 정보를 공유하는데 큰 역할을 함.

  • 텍스트 교환이므로 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안이슈 존재

  • 구조

    • 애플리케이션 레벨의 프로토콜.

    • TCP/IP위에서 작동.

    • 상태를 가지고 있지 않은 Stateless프로토콜

    • stateless프로토콜?

      서버 사이드에 클라이언트와 서버의 동작과 상태정보를 저장하지 않는 형태. 서버 응답이 클라이언트와의 세션 상태에 독립적임.

• HTTPS

  • Hyper Text Tranfer Protocal Secure

  • HTTP에 암호화가 추가된 프로토콜. 443번 포트를 사용함.

  • 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약.

  • 공개키 암호화 방식으로 텍스트를 암호화 함.(대칭키와 비대칭키 암호화 방식 모두 사용함)

  • HTTP보다 속도가 느림(차이가 느껴질 정도는 아님)

  • 인증서 발급과 유지에 비용이 발생함.

  • 암호화 복호화

    1. 서버와 클라이언트 간에 세션키(데이터 암호화를 위해 사용되는 대칭 키. 빠른 연산속도가 필요하므로 세션 키는 대칭키로 생성됨)를 교환함.

    2. 이 세션키를 클라이언트와 서버가 교환하는 과정에서 비대칭키가 사용됨.

       → 즉 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용. 이후 데이터 교환 과정에서 빠른 연산속도를 위해 대칭키가 사용됨.

  • HTTPS 연결과정

    1. 클라이언트(브라우저)가 서버로 최초 연결시도를 함
    2. 서버는 공개키(엄밀히 말하면 인증서)를 브라우저에게 넘겨줌
    3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함.
    4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키를 통해 세션키를 암호화 하여 서버로 전송함
    5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
    6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화 복호화를 진함.

    • 서버가 인증서를 넘겨주기 위한 과정

      • 일반적으로 인증된 기관에 공개키를 전송하여 인증서를 발급받음.

      1. 애플리케이션 서버를 만드는 ㄱ 기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급함

      2. ㄱ기업은 ㄴ기업(CA = Certificate Authoriy 기업. 공개키를 저장해주는 신뢰성이 검증된 민간기업)에게 돈을 지불하고 공개키를 저장하는 인증서의 발급과 관리를 요청함

      3. ㄴ 기업은 ㄴ기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고 ㄴ기업의 개인키로 암호화하여 ㄱ기업에게 이를 제공함

      4. ㄱ기업은 클라이언트에게 암호화된 인증서를 제공함.

      5. 브라우저는 ㄴ기업의 공개키를 미리 다운받아 가지고 있는 상태라 그 공개키를 가지고 암호화된 인증서를 복호화함.

      6. 암호화된 인증서를 복호화 하여 얻은 ㄱ 기업의 공개키로 세션키를 공유함

         → ㄴ기업의 개인키로 암호화되었기 때문에 신뢰성 확보 가능. 클라이언트는 ㄱ기업의 공개키로 데이터를 암호화 했기 때문에 ㄱ기업만 복호화 하여 원본 데이터를 얻을 수 있음.

URI, URL, URN

URI(Uniform Resource Identifier)

통합 자원 식별자라는 의미로 인터넷 상의 리소스 를 고유하게 식별할 수 있는 식별자

URI에는 위치를 알려주는 URL(Uniform Resource Locator) 와 전 세계를 통틀어 고유한 이름을 의미하는 URN(Uniform Resource Name) 이 존재한다.

• 하나의 리소스(ex. http에서 요청한 대상)를 가리키는 문자열.
• 여러 프로토콜에서 사용 가능
• 특정 형식이 존재하지 않고, 특정 자원을 식별하는 문자열을 의미 : URL이 아니고 URN도 아니면 그냥 URI
• URI 는 URL과 URN을 포함하는 개념이다.

URL(Uniform Resource Locator)

해당 위치에서 어떻게 리소스를 얻어낼 것인가에 대한 정보를 포함한다.
URL은 네트워크 상에서 리소스(ex. 웹 페이지, 이미지, 동영상 등의 파일)이 위치한 정보를 나타낸다.

ex) 현재 나라는 자원의 위치(거주지)가 대학교라면, 주소는 서울 용산구 청파동 2가 1-157, 명재관 404호

: 이 방에 나 혼자 산다면 나라는 자원에 대한 유일한 지시자 및 식별자 역할가능

but 룸메이트가 오게 되면 나라는 자원을 유일하게 지시하는 기준은 달라지게 됨 = 자원의 위치가 바뀔 수 있음
→ URN의 출현을 야기

• 인터넷에 있는 자원을 나타내는 유일한 주소 : URL이 존재하기 전 표준 없었을 때는 개발자들이 다양한 방식의 URI 형식을 만들어서 사용함
• 우리가 아는 일반적인 웹 주소 형식이다.
• 여러 프로토콜(ex. http, ftp, smtp)에서 사용가능
• 더 효율적으로 리소스 접근위한 방법론들 존재 ex. rest api

URL의 구성요소

• scheme(가장 먼저 작성) : 통신 방식(프로토콜)을 결정한다.
• hosts : 웹 서버의 이름, 도메인, IP를 사용하며 주소를 나타낸다.
• url-path : 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명
• query : 웹 서버에 보내는 추가적인 질문

URN(Uniform Resource Name)

리소스를 유일하고 영구적인 이름으로 식별하지만 접근방법과 인터넷 상의 위치는 알려주지 않는다.

매번 바뀌는 위치가 아닌 유일한 식별자인 이름을 기준 으로 자원을 식별하겠다는 의도이다.

• URN은 URI의 표준 포맷 중 하나로, 이름으로 리소스를 특정하는 URI이다.
• 불변 유일 : 하나의 리소스엔 절대로 겹치는 urn이 있으면 안된다. 불변이며 유일
• 실제 자원을 찾기 위해서 urn을 url로 변환하여 이용한다.

URL과 URN의 차이점

URL : 어떻게 리소스를 얻을 것, 어디에서 가져와야하는지 명시하는 URI

vs

URN : 리소스를 어떻게 접근할 것인지 명시하지 않고 리소스 자체를 특정하는 것을 목표로하는 URI이다.

URL, URN 예시

- **URL**
    - [http://example.com/mypage.html](http://example.com/mypage.html) (프로토콜: http)
    - ftp://example.com/download.zip (프로토콜: ftp)
    - [mailto:user@example.com](mailto:user@example.com) (프로토콜: mailto)
- **URN**
    - urn:isbn:0451450523 (책을 식별하는 ISBN 번호)
    - urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 (전 세계에서 유일한 번호)

포트와 소켓

host 란?

노드(node) : 네트워크에 연결된 모든 장치
host : node 중 ip 주소가 할당된 노드

네트워크상에서 데이터를 주고받는것 : 호스트의 프로세스까지 데이터가 오고가는것(호스트에는 여러 프로세스가 존재할수있음. 문맥교환… 기억하쥬?)

포트(Port)

프로세스(네트워크를 통해 데이터를 주고받는 주체)를 식별하기위해 호스트 내부적으로 프로세스에게 할당되는 고유값(number)

• 데이터를 받을때도, 보낼때도 필요

• 포트 번호 범위 : 0 ~ 65535번

  • 0 ~ 1023 : well-known port번호 영역입니다.
    이 영역의 port번호는 UNIX/LINUX에서 root 권한으로만 port를 열 수 있습니다. 일종의 예약영역
    • ex. 80번 http 통신
  • 1024 ~ 49151번 : 등록된 포트 (registered port)
    이 영역은 주로 서버 소켓으로 사용하는 영역
  • 49152 ~ 65535번 : 동적 포트(dynamic port), 개인포트로 서버가 클라이언트 식별시 사용

• 예시

    클라이언트 → 서버 (Request)
    - 출발지 포트 : 동적 포트 중 랜덤으로 선택한 숫자를 할당 (ex. 50000)
    - 목적지 포트 : 웹 서버 포트인 80을 입력
  
    서버 → 클라이언트 (Response)
    - 출발지 포트 : 웹 서버 포트인 80을 입력
    - 목적지 포트 : 클라이언트에게 받은 포트(ex. 위에서 사용한 50000번 포트)
    를 이용해서 데이터를 전송

소켓(Socket)

프로세스가 네트워크를 통해 데이터를 주고받기 위한 창구

하나의 프로세스가 하나의 포트를 가지고 여러개의 소켓을 열수 있음

→ 동시접속자수가 다수일수있음

Q&A

HTTPS란?

• HTTP에 공개키 암호화가 추가된 프로토콜. 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약.

소켓이 여러개일 경우 발생할 수 있는 문제점

• 소켓은 프로세스 하나당 여러개가 존재할수있음. 각 소켓도 CPU를 동시에(not 병렬적) 사용하기에 cpu 부담을 줄수도 있음. 특히 블락킹 방식의 소켓 통신중 문제가생겨 소켓이 블락되면 cpu 낭비가 심하다

HTTP의 문제점은?

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

소켓과 포트의 차이를 간략하게 설명

• 소켓은 특정 포트에서 데이터를 송수신하는 인터페이스이고 포트는 장치의 특정 프로세스 또는 프로그램에 할당된 식별자(숫자값)이다.
• 소켓은 컴퓨터 네트워크의 노드 내에서 데이터를 보내고 받기 위한 내부 Endpoint, 포트는 통신의 Endpoint에서 응용프로그램에 할당되는 숫자값
• 소켓이 특정 포트를 통해 데이터를 주고받는 인터페이스 역할, 포트는 특정 어플리케이션이나 프로세스를 식별하는데 도움을 준다.

HTTPS를 기반으로 웹사이트를 만들어야하는 이유?

• 구글이 HTTPS 웹사이트에 가산점을 주는 이유 때문에 HTTPS로 전환하게 되면 검색엔진 최적화(SEO)에 있어서 혜택을 볼 수 있습니다.
• 사용자들이 결국에는 가장 안전하다고 생각하는 사이트를 더 많이 방문하기 때문이기도 합니다.
• 가속화된 모바일 페이지(AMP, Accelerated Mobile Pages)를 만들고 싶을 때, HTTPS를 사용합니다. AMP란 모바일 기기에서 훨씬 빠르게 콘텐츠를 로딩 하기 위한 방법으로 구글이 만든 것입니다. 구글의 SERP (검색 결과 페이지)를 보면 모바일에서 사용하기 편하도록 AMP 콘텐츠들이 잘 보이는 것을 볼 수 있습니다.

HTTPS에서 대칭키 암호화 방식과 비대칭키 암호화 방식을 둘다 사용하는데 각각의 쓰임새는?

• 먼저 대칭키 암호화 방식은 빠른 연산 속도를 위해 데이터 간 교환에 사용한다. 따라서 세션키를 대칭키로 설정하고 이 키를 서버와 클라이언트가 교환한 다음 사용한다.
• 비대칭키 암호화 방식은 세션키로 대칭키를 사용한다고 했는데 이 세션키를 서버와 클라이언트가 처음 교환할 때 안전하게 교환하기 위하여 비대칭키를 사용한다

포트 번호가 필요한 이유는?

• 데이터를 주고받을 때 데이터는 정확한 호스트에 여러 프로세스 중 특정 프로세스로 전달되어야 한다. 따라서 호스트의 프로세스는 데이터를 보내기 전에 무조건 포트 번호를 할당 받아서 TCP혹은 UDP 헤더에 담아 요청을 해야 데이터를 받을 때 정확한 곳으로 배달이 오기 때문이다.

HTTP 통신과 소켓 통신의 차이

• HTTP 통신 : 클라이언트의 요청이 있을 때만 서버가 응답, 실시간 연결이 아닌 데이터 전달이 필요한 경우에만 요청을 보내는 상황에 유리(게시물에 대한 내용 요청)
• 소켓 통신 : 클라이언트와 서버가 특정 포트를 통해 양방향 통신을 하는 방식, 데이터 전달 후 연결이 끊어지는 것이 아니라 계속해서 연결을 유지 → HTTP에 비해 더 많은 리소스 소모, 클라이언트와 서버가 실시간으로 계속하여 데이터를 주고받아야하는 경우에 유리(실시간 동영상 스트리밍이나 온라인 게임 등에 사용)

HTTP 프로토콜의 특징?

• 1. 무상태 프로토콜(Stateless) : 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다. 즉, 무상태는 응답 서버를 쉽게 바꿀 수 있기에 서버의 확장성이 높다는 장점이 있지만, 클라이언트가 추가 데이터를 전송해줘야 하는 단점을 갖는다.

     → 서버가 클라이언트를 식별하지 못한다. 그래서 매번 새로운 인증을 해야하는 번거로움 때문에 서버가 클라이언트를 기억하기 위해 쿠키, 세션, OAuth, JWT 등을 사용한다!!

• 2. 비연결성 (Connectionless) : 클라이언트와 서버가 연결을 맺은 후, 클라이언트의 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질을 뜻한다.

     → 초 단위 이하의 빠른 속도로 응답이 가능하고, 계속 연결이 되지 않아 리소스를 아껴 더 많은 연결을 할 수 있다. but 매번 새로운 연결을 해야 하므로 오버헤드가 발생한다는 단점도 있다.

URI와 URN, URL를 간단하게 설명

• URI 는 네트워크 상 자원을 가리키는 일종의 고유 식별자(ID) 이다. URL, URN 은 URI 에 포함되는 개념이며 URL 은 자원의 위치, URN 은 자원의 이름 을 의미한다.

HTTP와 HTTPS의 차이

• HTTP의 동작순서는 TCP -> HTTP
• HTTPS의 동작순서는 TCP -> SSL -> HTTP로, SSL라는 암호화의 사용 유무가 차이