김영한 강사님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의를 수강하면서 정리하는 글입니다.
(🌙다크모드 권장,
중간중간 용어 정리도 할겸 작성하는 거라서 글의 길이가 길어질 수 있습니다. ^^)

작성중 나오는 이미지들은 제가 강의를 참고해서 직접 만드는 이미지입니다. 헤헤


🌐 인터넷 네트워크

client가 server에게 메세지를 보내려면 Internet Protocol을 따라야합니다.

💡프로토콜이란?
컴퓨터 내부, 또는 각 컴퓨터 간 데이터의 교환 방식을 정의하는 규칙입니다.

1. IP

Internet Protocol


1. 1 인터넷 프로토콜의 역할

지정한 IP Address에 데이터 전달

패킷(Packet)이라는 통신 단위로 데이터 전달

💡패킷(packet)이란?
pack + bucket을 합친말로 정보를 보낼 때 특정 형태를 맞추어 보낸다는 것입니다.
컴퓨터 간에 데이터를 주고받을 때 네트워크를 통해 전송되는 데이터 조각이라고 생각하시면 됩니다.

데이터를 조각내서 보내는 이유는 데이터가 클수록 대역폭을 많이 차지 하기 때문에 트래픽이 많아 집니다.

💡대역폭이란?
신호를 전송할 수 있는 주파수 범위를 말합니다.

💡트래픽이란?
서버, 스위치 등 네트워크 장치에서 일정 시간 동안 송수신되는 모든 데이터의 양을 의미합니다.

1. 1. 1 IP 패킷의 주요 정보

  • 버전 : 사용 중인 IP버전을 식별하는 데 사용 (IPv4 또는 IPv6를 가장 많이 사용)

  • TTL (Time to Live) : 해당 패킷이 네트워크에 남아있을 수 있는 시간

  • 출발지 (소스 주소) : 패킷을 네트워크로 보내는 장치의 IP주소

  • 도착지 (대상 주소) : 패킷이 전송되는 주소

  • 데이터

클라이언트가 패킷을 인터넷망에 던지면 각각의 노드들은 그림예시에 나와있는 200.200.200.2를 받을 수 있는 서버를 찾아서 던지다보면 결국 서버(200.200.200.2)에 패킷이 도달하게 됩니다.

노드들(서버)은 통신규약 갖고있기에 패킷 정보를 읽어서 패킷 정보가 주는 명세에 따른 작업을 수행할 수 있습니다.



클라이언트가 Hello, world! 메세지를 서버에게 보냈습니다.

서버 또한 클라이언트에게 메세지를 보낼수 있습니다.

클라이언트가 서버에게 요청을 보내는 인터넷망 경로와 서버가 응답을 보내는 경로는 다를 수 있습니다.


1. 1. 2 IP 프로토콜의 한계

1. 비연결성

  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

2. 비신뢰성

  • 중간에 패킷이 사라지는 경우 (패킷 소실)

    인터넷망에서 노드 별로 패킷 전달 과정에서 노드(서버)가 문제가 발생하면 패킷이 소실됩니다.

  • 패킷을 여러개 보냈을 때 순서대로 안오는 경우

    데이터가 커지면 패킷을 쪼개서 전달합니다. 하지만 패킷들이 같은 경로로 전달되는 게 아니기 때문에 보내는 이의 의도와 상관없이 패킷순서가 전달될 수 있습니다.

3. 프로그램 구분

  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션 둘 이상일 경우

이러한 문제들을 해결하는 게 TCP입니다.



2. TCP / UDP


2. 1. 프로토콜 계층

패킷이 생성되는 과정을 알아보겠습니다.

결과적으로 IP관련 정보가 있고 그안에 TCP정보가 있고 그안에 메시지 데이터가 들어있습니다.

해당 데이터가 LAN카드를 통해서 나갈때 이더넷 프레임이 포함되서 나갑니다.


2. 1. 1 TCP/IP 패킷 정보


2. 2. TCP 특징

전송 제어 프로토콜 (Transmission Control Protocol)

  • 연결 지향
  • 데이터 전달 보증
  • 순서 보장
  • 신뢰할 수 있는 프로토콜
  • 현재는 대부분 TCP 사용

2. 2. 1 연결지향

TCP 3 way handshake

TCP는 노드간 논리적인 접속을 성립하기 위해 3 way handshake를 사용합니다.

TCP 3 way handshake는 TCP/IP 프로토콜을 통해 Application이 데이터를 전송하기 전,
상대 컴퓨터와 사전에 세션을 수립(Established)하는 절차를 갖습니다.

1. SYN
client는 server에게 접속을 요청하는 SYN패킷을 보냅니다.
SYN을 보내면 SYN-Sent상태가 됩니다.

2. SYN + ACK
server는 client로부터 SYN를 받고 SYN-Received상태가 됩니다. 그리고 client에게 SYN+ACK가 설정된 패킷을 발송합니다.

3. ACK
client는 server로부터 SYN+ACK 패킷을 받고 ACK를 발송합니다.
(ACK와 함께 데이터를 전송할 수 있습니다.)
client는 Established상태가 됩니다. server도 ACK를 받으면 Established상태가 됩니다.

여기까지가 3 way handshake의 절차입니다.

4. 데이터 전송
위와 같은 방식으로 연결성이 맺어지면 데이터를 주고받을 수 있습니다.

TCP 연결이란 물리적인 연결이 아니라 논리적인 연결을 말합니다. (가상연결)


2. 2. 2 데이터 전달 보증

client가 데이터를 성공적으로 전송하면 server에서 데이터를 받았다고 client에게 알립니다.

2. 2. 3 순서 보장

패킷의 TCP 세그먼트안에 전송제어, 순서, 검증 등의 정보들로 패킷의 순서를 알 수 있고 순서가 잘못되면 해당 순서의 패킷부터 다시 보내라고 요청합니다.



2. 3. UDP 특징

사용자 데이터그램 프로토콜 (User Datagram Protocol)

  • 연결지향 X
  • 데이터 전달 보증 X
  • 순서 보장 X
  • 단순하고 빠름

IP(출발지, 목적지) + PORT(출발지, 목적지) + 체크섬 정도만 추가

💡체크섬이란?
체크섬(checkSum)은 중복 검사의 한 형태로, 송신된 자료의 값이 변경되었는 지를 검사하는 값으로 무결성을 제공합니다.



3. PORT


PORT는 위에서 언급한 IP 프로토콜의 한계에서 같은 IP에 여러 프로그램이 있으면 패킷을 어느 프로세스에 전달해야 하는지 명시하기 위해 사용됩니다.

IP가 컴퓨터를 찾기 위해 필요한 주소라면 PORT번호는 한 IP주소 내에서 수행되는 프로세스의 주소라고 생각하시면 될 것 같습니다.

김영한 강사님은 아파트에 비유를 하셨습니다.

IP : 동
PORT Number : 호


3. 1. 포트번호

포트번호는 0 ~ 65535번까지 있습니다.

0 ~ 1023번 포트는 잘 알려진 포트들(Well Known Ports)이라고 불립니다.

  • FTP - 20, 21
  • SSH - 22
  • TELNET - 23
  • DNS - 53
  • HTTP - 80
  • HTTPS - 443

잘 알려진 포트는 사용하지 않는 것이 좋습니다.

그 외의 경우 할당된 포트 번호들의 범위 내에서 응용프로그램의 프로세스가 생성될 때마다 일시적으로 부여됩니다.

💡잘 알려진 포트란?
TCP/IP의 상위 프로토콜을 사용하는 응용프로그램에서는 인터넷번호 할당 허가위원회(IANA)에 의해 미리 지정된 포트번호들입니다.



4. DNS

Domain Name System


IP 주소는 기억하기 어렵고 변경될 수도 있습니다.

이러한 불편함을 개선하기 위해 존재하는 게 DNS입니다.

4. 1. 도메인 네임 시스템

DNS는 전화번호부와 비슷합니다.

DNS는 사람이 읽을 수 있는 도메인 이름(ex: www.example.com)을 컴퓨터가 읽을 수 있는 IP 주소(ex: 192.0.2.14)로 변환해줍니다.

Client가 도메인 명으로 DNS 서버에 요청을 하면 해당 도메인에 IP주소를 반환받습니다.

반환 받은 IP주소로 Client가 Server에게 통신을 할 수 있게 됩니다.



5. URI

Uniform Resource Identifier

Uniform - 리소스를 식별하는 통일된 방식

Resource - 자원, URI로 식별할 수 있는 모든 것 (제한 없음)

Identifier - 다른 항목과 구분하는데 필요한 정보


URIURLURN이라는 하위 타입을 갖고 있습니다.

즉,
모든 URLURI라고 할 수 있고, URN역시 URI이라고 할 수 있습니다.

엄밀히 따지면 URLURI는 다르지만, 대부분의 사람들은 같은 의미로 해석합니다.



5. 1. URL

Uniform Resource Locator

Locator - 리소스가 있는 위치를 지정

  • scheme

    • 주로 프로토콜을 사용 ex) http, https, ftp 등등
  • host

    • 도메인 또는 IP 주소
  • port

    • 접속 포트
    • 일반적으로 생략, 생략시 http는 80, https는 443
  • path

    • 리소스 경로, 계층적 구조
    • ex) /home/file1.jpg, /members/100
  • query

    • key=value 형태
    • ?로 시작, &로 추가 가능
    • query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태


5. 2. URN

Uniform Resource Name

Name - 리소스에 이름을 부여

URN은 리소스에 고유한 이름을 부여해서 구분하는 방식입니다.

URN의 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않습니다.




🌐 HTTP 기본

1. HTTP

HyperText Transfer Protocol


HTTP 메세지에 모든 것을 전송

  • HTML, TEXT

  • IMAGE, 음성, 영상, 파일

  • JSON, XML (API)

  • 거의 모든 형태의 데이터 전송 가능

  • 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

💡JSON이란?
"JavaScript Object Notation" 의 약자로
데이터를 저장하거나 전송할 때 많이 사용되는 경량의 DATA 포맷으로 어떠한 통신 방법, 문법도 아닌 단순히 key-value 쌍의 데이터를 표시하는 방법으로 사용됩니다.

사람과 기계가 모두 이해하기 쉽고 용량이 작아서, 최근 JSON이 XML을 대체하는 사례가 많아지고 있습니다.


1. 1. HTTP 역사

  • HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X

  • HTTP/1.0 1996년: 메서드, 헤더 추가

  • HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

    • RFC2068 (1997) ▷ RFC2616 (1999) ▷ RFC7230~7235 (2014)
  • HTTP/2 2015년: 성능 개선

  • HTTP/3 진행 중: TCP 대신 UDP 사용, 성능 개선


1. 2. 기반 프로토콜

HTTP/2 와 3는 1.1을 보완한 프로토콜입니다.

  • TCP : HTTP/1.1, HTTP/2

    • HTTP/2의 개선점
      HTTP/1.1까지는 한 번에 한 파일밖에 못 보냈다. 그래서 특정 파일의 로딩이 늦어지면 다른 파일까지 줄줄이 느려지는 병목 현상이 생기게 된다. 그래서 여러 파일을 한꺼번에 병렬 전송을 하는 식으로 로딩 시간을 줄이는 방법을 사용한다.
      HTTP/2에서는 헤더를 압축하여 용량 대비 처리 효율성을 높이는 방법을 사용한다. 압축을 하기 때문에 헤더 크기 자체도 크게 줄어든다.
  • UDP : HTTP/3

    • HTTP/2와 차이
      일반적인 웹 환경에서는 HTTP/2와 HTTP/3의 차이가 크지 않을 수 있으나, 동영상 서비스 등에서는 큰 차이를 보인다. 예를들어, 모바일 기기처럼 인터넷 연결 상태가 고르지 못한 경우라든지, WiFi에 연결하여 동영상을 시청하는 도중에 자리를 이탈하여 셀룰러 신호로 바뀌더라도 HTTP/3로 연결되어 있으면 영상을 끊김없이 시청할 수 있다. 패킷 전송에 있어서 제약이 거의 없는 비연결성 전송 계층을 기반으로 TCP 프로토콜의 무결성 보장 알고리즘과 SSL이 이식됨으로써 높은 성능과 동시에 충분히 괜찮은 정확성과 부인방지 특성을 충족시켰다.
  • 현재 HTTP/1.1 주로 사용
    • HTTP/2, HTTP/3도 급속도로 증가하는 추세

1. 3. HTTP 특징

  • 클라이언트 서버 구조

  • 무상태(Stateless) 프로토콜, 비연결성

  • HTTP 메세지

  • 단순함, 확장 가능


1. 3. 1 클라이언트 서버 구조

Request - Response 구조

  1. 클라이언트가 서버에게 요청 -> 응답 대기
  2. 서버가 요청에 대한 결과를 만들어서 응답

1. 3. 2 무상태(Stateless) 프로토콜

1. 상태 유지 - Stateful

클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미합니다.
클라이언트의 이전 요청이 서버에 전달되었을 때, 클라이언트의 다음 요청이 이전 요청과 관계가 이어지는 것을 의미합니다.
만약 대량의 트래픽이 발생할 경우 서버를 긴급하게 늘린다면, 바뀐서버는 클라이언트의 상태를 모르기 때문에 요청 처리 과정에 문제가 발생합니다.

2. 무상태 - Stateless

무상태는 새로운 서버를 생성해도 비즈니스 로직만 있다면, 이전의 사용자 요청과 관계없이 계속 일을 처리할 수 있습니다.
단점은 클라이언트의 최종 목적을 위해 지나는 과정마다 점점 전달할 내용이 많아집니다.
장점은 무한한 서버 증설 가능하다는 점입니다.

3. 실무 한계

  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우가 존재
  • 무상태
    • ex) 로그인이 필요 없는 단순한 서비스
  • 상태 유지
    • ex) 로그인 - 로그인 했다는 상태를 서버에 유지
    • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
    • 상태 유지는 최소한만 사용

1. 3. 3 비연결성

  • HTTP는 기본적으로 연결을 유지하지 않는 모델

  • 서버 자원을 매우 효율적으로 사용

비연결성 한계 및 극복

  • TCP/IP 연결을 서버마다 새로 맺고 끊어야함 (3,4 way handshake 시간 추가)

  • 웹 브라우저로 사이트를 요청시, HTML + js + css + 추가 이미지 등 수많은 자원이 함께 다운로드

    • 현재는 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2,3 에서 훨씬 최적화

1. 3. 4 HTTP 메세지



👀참조



https://enlqn1010.tistory.com/9

https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake

https://it-sungwoo.tistory.com/128

https://aws.amazon.com/ko/route53/what-is-dns/

https://mygumi.tistory.com/139

https://danielmiessler.com/study/difference-between-uri-url/

https://genesis8.tistory.com/195

https://namu.wiki/w/HTTP/3

https://irostub.github.io/web/stateful-stateless/

4개의 댓글

comment-user-thumbnail
2022년 6월 9일

짱이네용 😮😮😮😮😮 👍

1개의 답글
comment-user-thumbnail
2022년 6월 10일

정말 깔끔하게 정리하셨네요! 잘 봤습니다!! 😉

1개의 답글