HTTP

 

IP 주소를 통해 클라이언트와 서버는 상호 통신이 가능하다. (IP는 인터넷 주소)

패킷이라는 통신 단위로 데이터를 전달한다.

출발지와 목적지 IP를 적어서 IP 패킷을 전달한다.

 

클라이언트에서 서버로 가능 방법과 서버에서 클라이언트로 가는 방법은 다를 수 있다.

 

IP 프로토콜의 한계

비연결성

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

비신뢰성

 - 중간에 패킷이 사라지면? (패킷 소실)

 - 패킷이 순서대로 안오면? (패킷 전달 순서 문제 발생)

         - 패킷의 크기가 클 경우 나눠서 발송을 함, 보내는건 순서대로지만 도착은 순서대로 도착한다는 보장은 없다.

프로그램 구분

 - 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면 (한개의 컴퓨터로 게임도 하고, 음악도 들고 다양한 일을 할 경우)

 

TCP 프로토콜이 이러한 문제를 해결해준다.

 

인터넷 프로토콜 스택의 4계층

애플리케이션 계층 - HTTP, FTP

전송 계층 - TCP, UDP

인터넷 계층 - IP

네트워크 인터페이스 계층 - 랜카드, 랜드라이버

 

만약 내가 채팅 프로그램으로 "Hello"라는 데이터를 전달하려고 한다면

소켓 라이브러리를 통해서 OS 계층에 "Hello" 라는 데이터를 전달한다.

그 위에 TCP 정보를 씌워주고 (출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보)

그 위에 IP와 관련된 데이터를 씌워주고 (출발지 IP, 목적지 IP)

마지막으로 Ethernet frame을 씌워서 전달한다.

 

 

TCP 특징

1. 연결지향 (클라이언트와 서버간의 연결을 완료한 후에 메세지를 보낸다.) - TCP 3 way handshake (가상 연결)

2. 데이터 전달 보증 (메세지가 중간에 누락되었으면 내가 알 수 있도록 한다. 연결이 되면 응답을 보내고, 연결이 안되면 응답을 안보냄)

3. 순서 보장(패킷의 순서를 외워놨다가, 패킷의 순서가 잘 못 되었을 경우 서버가 클라이언트에게 잘 못된 부분부터 다시 요청)

 

 

클라이언트에서 서버로 syn

서버에서 클라이언트로 syn + ack

클라이언트에서 서버로 ack

3번의 통신이 왔다 갔다 하며, 이는 물리적인 연결이 아닌 논리적 (가상의) 연결이다.

 

UDP

tcp는 3way hadshake를 하고 연결을 하고 받았다는 알림도 보내는 등 절차가 많아 최적화를 하기가 어렵다. 

UDP는 절차가 적고, 웹 브라우저에서 더욱 최적화를 하는 방법으로 UDP가 예전보다는 점점 더 많이 쓰이는 추세다.

 

하얀 도화지에 비유(기능이 거의 없음)

• 연결지향 - TCP 3 way handshake X

• 데이터 전달 보증 X

• 순서 보장 X

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

• 정리

• IP와 거의 같다. +PORT +체크섬 정도만 추가 • 애플리케이션에서 추가 작업 필요

 

PORT, 하나의 IP에서 여러가지 일을 할 수 있도록 만들어주는 것이다.

 

PORT

port를 알아보자.

r

같은 ip 내에서 프로세스를 구분하는 방법이 위와 같다

예)

웹 브라우저 같은 경우에는 200.200.200.3 번 ip에 80 port로 데이터를 보내고

웹은 클라이언트에게 100.100.100.1 ip에 10010 port로 html를 받는다.

웹이 우리의 ip 정보를 아는 이유는 우리가 패킷보낼때 출발지 ip를 같이 보내기 때문이다.

 

0 ~ 65532 할당 가능

0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음

FTP - 20, 21

TELNET - 23

HTTP - 80

HTTPS - 443

 

DNS (domain name system)

---

ip는 기억하기가 어렵다

ip는 변경될 수 있다.

 

dns를 사용하면서 우리에게 익숙한 도메인으로 접속이 가능하고

dns서버에는 도메인명과 ip를 연결하게 된다.

물론 도메인 명은 서버쪽에서 직접 구매를 한 것이다.

 

 

URI (Uniform Resource Identifier)

---

URI? URL? URN?

URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.

URL: 웹브라우저에서 보던 형식 (http://www.naver.com)

URN: 직접 이름을 붙여주는 형식

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

Resource: 자원, URI로 식별할 수 있는 모든 것 (제한 없음, 웹브라우저 html, 파일, 실시간 교통정보 등등..)

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

 

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

URN - Name: 리소스에 이름을 부여

위치는 변할 수 있지만, 이름은 변하지 않는다.

    - urn:isbn:8960777331 (1. 자바 ORM 표준 JPA 프로그래밍 책의 isbn URN)

    - URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음

    - isbn 값으로 검색해보면 상당히 까다롭다는 것을 알 수 있다.

 

앞으로 URI를 URL과 같은 의미로 이야기하겠다.

 

URL 분석

 

http 요청 흐름

---

먼저 DNS 서버를 조회하여 DNS에 해당하는 IP를 확인한다.

https이기 때문에 port정보는 443인 것을 확인한다.

http 요청 메세지를 생성한다.

http 요청 메세지는 아래와 같다.

 

 

GET , path, query, http version 정보, host 정보 등등이 기록되어있다.

 

전송 흐름을 살펴보자.

 

애플리케이션 계층

1. resource 요청 시 웹 브라우저가 http 메세지를 생성

2. SOCKET 라이브러리를 통해 전달

 - A: TCP/IP 연결(IP, PORT), syn, syn/ack, ack 3way handshake 로 연결 확인 (클라이언트와 서버 간의 논리적 연결을 진행)

 - B: TCP/IP 계층 (OS 계층) 으로 데이터 전달

 

TCP/IP 계층 (OS 계층)

HTTP 메시지 포함된 TCP/IP 패킷 생성을 생성한다. 패킷은 아래와 같은 형태일 것이다.

 

패킷 정보가 인터넷으로 흘러간다.

서버에 요청  패킷이 도착하여 패킷 껍데기는 버리고 HTTP 메시지를 서버가 해석한다.

 

서버에서도 동일하게 HTTP 응답 메시지를 생성하고

TCP/IP 패킷 형태로 만들어서 웹 브라우저에 전달한다.

 

수 많은 노드들을 통해서 응답 패킷이 도착하게 되면 웹 브라우저가 HTML 렌더링하여 화면에 보여준다.

 

 

HTTP (HyeprText Transfer Protocol)

---

HTML, TEXT

IMAGE, 음성, 영상, 파일

JSON, XML (API)

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

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

지금은 HTTP 시대라고 할 수 있다.

 

현재까지는 HTTP/1.1 을 많이 사용하고 있다.

 

Chrombrowser -> 우클릭 검사 -> Network -> Name 우클릭 -> Protocol 을 클릭하면 HTTP version을 확인할 수 있다.

구글에서는 현재 http3를 사용하고 있는 모습이다.

 

HTTP의 특징

 - 클라이언트 서버 구조

 - 무상태 프로토콜(스테이트리스), 비연결성

 - HTTP 메시지를 통해서 통신 (보낼때도 받을때도)

 - 단순함, 확장 가능

 

 

클라이언트 서버 구조

request, response 구조

클라이언트가 메세지에 요청을 보내고, 클라이언트는 서버에서 응답이 올 때까지 대기,

서버로 부터 응답이 오면 클라이언트 동작

 

예전에는 클라이언트와 서버 개념이 분리 되어있지 않았지만 현재는 분리되어 있다.

비즈니스 로직과 데이터는 모두 서버에 넣어놓고

클라이언트는 UI 사용성에 집중

이로 인해 클라이언트와 서버는 각각 독립적으로 발전 가능한 장점이 있다. 각각의 역할에만 집중하면 된다.

 

무상태 프로토콜

서버가 클라이언트의 상태를 보존하지 않는다.

장점: 서버 확장성 높음(스케일 아웃)

단점: 클라이언트 

 

Stateful

Stateless