HTTP와 네트워크 간단정리

Sorbet·2021년 2월 1일

공지...

노션에 적은 글을 벨로그로 옮겼습니다.

많은 패치와 수정속에서 글이 보기 좋지않게되었습니다. 해당 문서는 아래 노션 링크를 참조해주세요

https://www.notion.so/TCP-IP-HTTP-f93939d5068348939180acef92bf2bae

Protocol (프로토콜)

: 인터넷 네트워크, 혹은 웹이라는 기술에서 쓰이는 용어인데

정보를 주거나 받기 위해서 지켜야 할 규칙 (약속)

프로토콜이 맞는 예

req) 번호좀 알려주세요

res) 010 - 1234 - 5678
프로토콜이 맞지 않는 예

req) 번호좀 알려주세요

res) 010 - 001 010 011 100 - 101 110 111 000 오버플로익셉션인데요?

req).. (도망)
너무 당연하지만 사람들사이에서 숫자를 말할때는 당연히 10진수로 말해야한다는 규칙이 있다. 이것또한 일종의 프로토콜
실제로 다양한 프로토콜을 사용하는 예시를 보면
- TCP : Transmission Control Protocol
- IP : Internet Protocol
- UDP : User Datagram Protocol
- Https : secure Hyper Text Transer Protocol
- Http : Hyper Text Transer Protocol
- FTP : File Transfer Protocol
```
 sFTP, FTPs, tFTP
```
- Telnet : Terminal Network
- SSH : Secure Shell
- SMTP : Simple Mail Transfer Protocol

TCP

TCP, IP, Packet

: HTTP는 TCP/IP 로 이루어졌다는데 이건 또 뭘까?

TCP : Transmission Control Protocol, 전송 제어 프로토콜

: Transmission Control, 즉 전송제어를 달성하기 위해서는 몇가지 핵심 특징이 있는데
- 연결의 시작과 끝 : 3-way handshaking, 4-way handshaking
- Flow Control : 흐름제어
- Congestion Control : 혼잡제어
- Packet Switching : 패킷 스위칭, TCP/IP 이전에는 패킷스위칭이 아닌 써킷스위칭이라서 회선의 중간에 하나를 단선시키면, 네트워크가 불능이 되는 방식이였다
  
  : 그리고, 이 패킷 스위칭 덕분에, 중간에 패킷이 하나가 분실되도 재 전송을 요청하면 되기 때문에, 데이터의 무결성을 보장할 수 있다. 그래서 이메일이나 소스코드, 파일전송과 같은 분야에 쓰임
IP : Internet Protocol, 인터넷 프로토콜

: 모든 컴퓨터에 주소(Address)를 할당해서 각 컴퓨터에게 필요한 정보를 전송한다. 이 인터넷상의 주소를 IP Address 라고 부른다.
Packet , 패킷 이란 네트워크 상에서 정보를 주고받을 때 쓰는 "표준택배상자"
- 패킷은 Header / Body로 이루어져 있는데
- Header : 택배로 치면 송장 어디로 가야하는지 등등, 메타 데이터가 들어있음
- Body : 택배로 치면 내용물 , 데이터가 들어있음
Capsulation : 위의 패킷에서 택배를 싸는데, 내용물만 보내는게 아니라 내용물에다가 택배상자를 붙이고, 완충재를넣고, 테이프를 붙여서 마감하고, 접수하고, 송장을 붙이는것까지의 일련의 과정이 있다. 이러한 과정을 Capsulation
- ENCapsulation : 택배를 싸는과정
- DECapsulation : 택배를 푸는 과정, 이건 택배를 쌀때의 반대순서로 작업을 하면 된다.
  
  결론 : Capsulation 의 정확한 정의는 데이터를 Packet이라는 택배박스에다가 목적지 까지 잘 갈수 있도록 포장하고, 받고도 택배박스에서 내용물을 꺼내기까지 모든 과정에 대한 작업을 지칭함

Layer

: OSI-7레이어라는게 있다는데, 내가 봤을때 이건 안다룰수 없으면서도 왜다루는지 모르겠다.

내 생각에 이건 마치 군대에서 그냥 판쵸우의 갈아입는 법을 판쵸우의 착용 7단계 구분동작으로해서 숙련된 조교의 시범과 함께 구분동작으로 배웠는데

네트워크도 그냥 필요해서 만들다 보니까 여러 기술들이 섞이고 섞이게 됬고 이걸 나중에 좀 구분할 필요가 있어지다 보니까 존나 멋있게 7레이어로 구분지은 느낌이랄까.

7레이어를 완벽하게 알아서 얻을수 있는거라곤 정보처리기사 시험문제를 맞출수있다. 그러니까 그냥 이런게 있구나 하고 넘어간다

지금까지 기반기술들을 좀 정리했다면 아래로는, HTTP에 대하여 좀더 자세히 공부하겠습니다.
어차피 위에서 공부했던 키워드는 거의 써먹을일이 없고, HTTP지식은 쓸일이 많으니까요,

3-Way Hand shaking

TCP/IP에서 연결이 성립하기 위해서는 메시지가 3번(3-way) 오고가야 되는데 이거를 악수같다고 해서 부르는 이름

SYN: 클라이언트가 서버에게 SYN 메시지를 보낸다. 이 메시지에 포함된 시퀀스 번호는 클라이언트가 임의로 설정한 값 A.

SYN-ACK: 서버가 클라이언트에게 SYN-ACK 메시지로 응답한다. 이 메시지에 포함된 시퀀스 번호는 서버가 임의로 설정한 값 B, 응답 번호는 (A + 1).

ACK: 클라이언트가 서버에게 ACK 메시지를 보낸다. 이 메시지에 포함된 응답 번호는 (B + 1).

DNS

: 네이버를 접속하기 위해서 www.naver.com 을 써야되는데, 20.157.56.222 같은 IP 주소로 접속하는 사람은 없다. 근데, 컴퓨터는 저런 숫자로 말해줘야 되기 때문에,

인간의 주소와 컴퓨터의 주소를 변경해주는 서버 혹은 그런 시스템을 DNS 라고 부른다.

HTTP란?

: HyperText Transfer Protocol

이거를 하나하나 쪼개서 생각해보면
HyperText : 글자를 누르면 페이지가 열려!(HTML)
Transfer Protocol : 데이터를 주고받는 약속을 정해놨음!
HTTPS는? : HTTP + Scure, 안전하다

좀더 자세한 HTTP 설명

HTTP의 가장큰 특징은 1요청당 HTML페이지 하나만 전송하고 연결이 종료됨
위에서 HTTP 는 요청-전송-연결종료 순서로 이루어진다 했는데, 여기서

요청 : Request : 클라이언트가 서버에게 보내는 메시지

전송 : Response : 서버가 클라이언트에게 응답하는 메시지
실제로 HTTP 의 요청과 전송할때는 바이트단위의 "메시지"로 주고받는데, 아주 간략하게 살펴보면 아래 그림

HTML이란?

: Hyper Text Markup Language

Hyper Text : text를 넘어서 링크, 이미지 등 다양한 것들을 표현할 수 있는 것
Markup Language : 프로그래밍 랭귀지랑 다르다는 의미에서 마크업 랭귀지

: 프로그램이, 미리 코딩한(pro) 내용을 읽어가며 실행(gram) 하는 것과는 다르게

: 뼈대만 만드는(Markup) 그러한 언어라는 의미에서 마크업 랭귀지라고 부름
- 앞에서 뼈대만 만든다고 했는데, 여기서 생략된 주어는 "웹페이지의 뼈대"
그래서 결론은

HTML이란, 웹 문서의 뼈대를 구성하는 언어

브라우저를 통해서 웹 문서를 읽을 때, 전체적인 틀을 잡아주는 언어

HTTP 응답상태코드

대표적인 HTTP 상태코든는 아래와

등등 많음... MDN보셈

이 상태코드들은 웹페이지의 응답 (response)할때 헤더에 붙어서 해당 요청에 대한 처리결과를 사용자에게 알려주는 역할을 함

HTTP 메서드

get, post, put, delete

일단 가장 좋은 자료가 많은 MDN에 의하면

GET : GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.

HEAD : HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.

POST : POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.

PUT : PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.

DELETE : DELETE 메서드는 특정 리소스를 삭제합니다.

CONNECT : CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.

OPTIONS : OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.

TRACE : TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.

PATCH : PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

HTTP 메소드는 이런거인데..

: 나중에 REST API랑도 연관되니까 알아두세요 (여기다 resource, message만 첨가하면 됨)

GET : 리소스획득

리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요청한다. 내용은 지정된 리소스를 서버가 해석한 결과이다.

리퀘스트

GET / index.html HTTP /1.1
Host : www.xxx.xx

리스폰스

index.html 리소스를 돌려준다.

리퀘스트

GET /index.html HTTP /1.1
Host: www.xxx.xx
If-Modified-Since: Thu. 12 Jul 2012 07:30:0 GMT

리스폰스

index.html 리소스가 지정날짜 이후에 갱신된 경우에만 리소스를 돌려준다. 그 이전이라면 상태코드 304 Not Modified 리스폰스를 돌려준다.

POST : 엔티티 전송

GET으로도 전송가능하지만 주로 POST로 전송한다.

리퀘스트

POST / submit.cgi HTTP/1.1
Host : www.xxx.xx
Content-Length:1500(1560바이트)

리스폰스

submit.cgi가 수신한 데이터의 처리한 결과를 되돌려준다.

PUT : 파일전송

FTP에 의한 파일 업로드와 같이, 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구한다.

HTTP/ 1.1 자체에는 인증기능이 없어 누구든지 파일을 업로드 가능하여 보안 상의 문제가 있다. 웹 애플리케이션에 의한 인증기능기능과 같이 쓰이거나 REST와 같이 웹끼리 연계하는 설계양식을 사용할때 이용한다.

리퀘스트

PUT / example.html HTTP /1.1
Host: www.xxx.xx
Content-type:text/html
Content-Length: 1500(1560바이트)

리스폰스

상태코드 204 Not NoContent 리스폰스를 돌려준다.

HEAD : 메시지 헤더 취득

GET과 같지만 메시지 바디는 돌려주지 않는다. URI 유효성과 리소스 갱신 시간을 확인하는 목적으로 사용된다.

리퀘스트 , 리스폰스

HEAD /index.html HTTP/1.1
Host: www.www.ww

index.html에 관련된 리스폰스 헤더를 돌려줌.

DELETE : 파일 삭제

리퀘스트 URI로 지정된 리소스의 삭제를 요청한다. 인증기능이 없어 웹애플리케이션등에 의한 인증기능과 사용하며 REST사용하는 경우 사용된다.

DELETE /example.html HTTP/1.1
Host: www.www.ww

상태코드 204 Not Content의 리스폰스를 돌려준다.

OPTIONS: 제공하고 있는 메소드 조사

리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사

OPTIONS * HTTP/ 1.1
Host: www.ww.www

HTTP /1.1 200 OK
Allow : GET, POST, HEAD, OPTIONS

TRACE: 경로조사

웹 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킨다.

CONNECT: 프록시에 터널링 요구

HTTP 속성

안전, 멱등[idempotente], 캐시가능[캐셔블]

9.5) HTTP 메시지(REQUEST, RESPONSE)

위에서 배운것처럼, HTTP 를 이용한 통신에서는
- 클라이언트로부터 리퀘스트가 송신되며
- 그 결과는 서버로부터 리스폰스로 응답한다
즉 클라이언트로 부터 통신이 시작되며, 서버는 리퀘스트를 수신하지 않으면 리스폰스가 발생하는 경우는 없다.
HTTP 메시지는 복수 행(개행 CR+LF)의 데이터로 구성된 텍스트 문자열이다.
크게 구분하면 메시지 헤더와 메시지 바디로 구성되어 있고, 최초에 나타나는 개행 문자로(CR+LF) 메시지 헤더와 바디를 구분한다. 메시지 바디가 항상 존재한다고는 할 수 없다.
http 메시지(리퀘, 리스폰)는 기본적으로 3가지 구성요소가 있는데

: 메시지 헤더, CR+LF, 메시지 바

REQUEST

리퀘스트 메시지는 메소드, URI, 프로토콜버전, 옵션 리퀘스트 헤더필드 엔티티로 구성되어있다
리퀘스트를 받은 서버는 내용을 처리한 결과를 리스폰스로 되돌려 준다.
리스폰스 메시지는 프로토콜 버전, 상태코드, 상태코드설명 프레이즈, 옵션의 리스폰스 헤더필드와 바디로 구성되어 있다.
클라→ 서버 : 리퀘스트 보내기 메시지의 내용 1

GET /index.html HTTP/1.1
Host: www.xxxx.xxx

내용 설명
- GET : 서버에 요구하는 종류, 메소드이다.
- index.html : 요구 대상인 리소스를 나타낸다. 리퀘스트 URI라 한다.
- HTTP/1.1 : 클라이언트 기능을 식별하기 위한 HTTP 버전 번호.
  - HTTP 서버 상에 있는 /index.html 리소스가 필요하다는 리퀘스트 이다.
리퀘스 보내기 메시지의 내용 2

POST/ form/entry HTTP/1.1
Host : www.xxx.xxx

RESPONSE

HTTP /1.1 200 OK
response header field
body

HTTP 특징

13) HTTP 특징

무상태(stateless), 상태유지, 지속연결, 비지속연결

무상태(stateless)

: state, 즉 상태가 less없다는 말

앞에서 말한거처럼, HTTP는 단한번만 통신하고 끊어지는데, 그렇기 때문에 상태를 저장하지 않는다, 상태가 없다.
서버, 클라 서로 요청한것을 기억하지 못한다.

: 다만, 서버가 클라이언트를 기억하는 기법은 "세션/저장소" 같은 방식으로 이용하여 기억하는것처럼 동작하게 한다
서버와 클라이언트 각자 통신은 독립적이며 1회 수행하고 끊어진다는 점을 기억하자
클라이언트에게서 요청메시지를 받고 응답하는데, 서버는 클라이언트에 관한 어떤 상태정보도 저장하지 않는다.
만약 클라이언트가 몇초 후에 같은 객체를 두번 요청한다면 잠시전에 이미 그 객체를 보냈다고 해도 서버에게 알려주면 좋지만 서버는 이전에 한 일을 기억하지 못한다.

상태유지(웹에서의 상태 유지 기술)

HTTP프로토콜은 상태 유지가 안되는 프로토콜입니다. 이전에 무엇을 했고, 지금 무엇을 했는지에 대한 정보를 갖고 있지 않습니다. 웹 브라우저(클라이언트)의 요청에 대한 응답을 하고 나면 해당 클라이언트와의 연결을 지속하지 않습니다.
상태 유지를 위해 Cookie와 Session기술이 등장합니다. 즉, 클라이언트가 두 번째, 세 번째 요청을 했을 때에는 이 클라이언트가 누구이구나라는 정보를 알게 한다거나 등등 여러 가지의 이런 상태를 유지해 주기 위한 기술인 Cookie와 Session이 등장하게 됩니다.
쿠키
- 사용자 컴퓨터에 저장. 유지해야 할 정보를 사용자 컴퓨터에 저장하게 하는 기술
- 저장된 정보를 다른 사람 또는 시스템이 볼 수 있는 단점
- 유효시간이 지나면 사라짐
세션
- 서버에 저장
- 서버가 종료되거나 유효시간이 지나면 사라집니다.

출처 : https://nbkw.tistory.com/148

비지속연결

: non-persistent 비지속연결이란,

: HTTP 1.1표준에서는 연결 방법은 두가지인데, 지속연결 비지속연결 두가지가 생김

HTTP 는 기본적인 컨셉이 온디멘드(on-demand) 방식으로 동작.

on-demand란, 그들(클라이언트, 사용자)이 원할 때 원하는 것을 수신한다.
그리고, HTTP는 비상태 프로토콜(stateless) → 서버에서 클라이언트에 대한 정보를 유지하지 않음.
- 그래서, 클라이언트에서 수초내에 요청했던 페이지를 다시 요청해도 다시 객체를 계속 다시 전송함. F5 키를 연타하면 사망해버리는 학교 수강신청서버를 생각하면 된다
비지속연결은 각 요청객체마다 새로운 연결이 설정되어야 함.

-> TCP버퍼가 할당되어야 하고 TCP변수들이 클라이언트와 서버 양쪽에 유지 되어야 함으로 웹서버에 심각한 부담을 줌.

-> 또한 각 객체마다 2RTT를 필요로 하는데 이를 별도로 진행해야 함으로 성능이 떨어짐.
RTT란?

-> 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트에게 돌아오는 데 걸리는 시간 RTT(round-trip time)

지속연결

지속연결:persistent : HTTP/1.0에서 TCP 연결문제 해결을 위해 등장한 기술

HTTP/1.1, HTTP/1.0에서 TCP 연결문제를 해결하기 위해 지속연결 방법이 고안
지속연결의 특징은 어느 한쪽에 명시적으로 연결을 종료하지 않으면 TCP 연결을 계속 유지한다.
지속연결의 이점은 TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주어 서버 부담이 줄어든다.
오버헤드를 줄인만큼 리퀘스트/리스폰스가 빨라진다.
지속연결은 HTTP /1.1에서는 표준 동작이지만 HTTP/1.0에서는 정식 사양이아니다.
HTTP의 default mode는 파이프라이닝을 이용한 지속연결이고, 비지속 연결은 TCP연결이 다른 객체를 전송하기 위해 유지 되지 않는 연결방식.
- 즉 한개의 TCP연결은 하나의 요청메시지와 하나의 응답메시지만 전송가능
- 그래서 웹페이지에 다양한 객체가 포함되어 있다면 객체의 수만큼 TCP연결이 필요함.
- 즉 사용자수만큼 서버의 쓰레드 생성이 필요한데 서버 동시접속자 10만명이라면, 서버는 10만개의 쓰레드가 필요함
지속연결은 서버가 클라이언트의 요청의 대해서 응답한 후 TCP연결을 유지하는 방식으로,같은 클라이언트-서버간의 요청-응답이 동일한 TCP연결을 통해 이루어지는 연결방식.

비지속 VS 지속

<비지속연결 vs 지속연결>

요구/응답쌍이 분리된 TCP연결을 통해 보내져야 하는가?---> 비지속연결
요구와 해당하는 응답들이 같은 TCP연결상으로 보내져야 하는가?--->지속연결

비지속연결 HTTP:

HTTP클라이언트는 HTTP의 기본포트번호 80을통해 www.someschool.edu서버로 TCP연결을 시도한다. TCP연결과 관련하여 클라이언트와 서버에 각각 소켓이있게된다.
HTTP클라이언트는 1단계에서 설정된 TCP연결소켓을 통해 서버로 HTTP요청메시지를 보낸다. 이 요청메시지는 /somedepartment/home.index 경로 이름을 포함한다.
HTTP서버는 1단계에서 설정된 연결소켓을 통하여 요청메시지를 받는다. 저장장치로부터 /somedepartment/home.index객체 추출, HTTP응답메시지에 그 객체를 캡슐화 한다. 그리고 클라이언트로 전송
HTTP서버는 TCP에게 TCP연결을 끊으라 한다.(그러나 실제로 TCP클라이언트가 응답메시지를 받을 때까지 연결을 끊지 않는다)
HTTP클라이언트가 응답메시지를 받으면,TCP연결이 중단된다. 메시지는 캡슐화된 객체가 HTML인것을 나타낸다. 클라이언트는 응답메시지로부터 파일을 추출하고 HTML파일을 조사하고 10개의 JPEG객체에 대한 참조를 얻는다.
그 이후에 참조되는 각 JPEG객체에 대해 처음 4단계를 반복한다.

비지속 연결을 사용하므로 각 TCP연결은 하나의 요청메시지와 하나의 응답메시지만 전송,그래서 위는 사용자가 웹 페이지 요청시 11개의 TCP연결이 만들어진다.

지속연결 HTTP:

비지속연결의 단점: 각 요청객체에 대한 새로운 연결이 설정되고 유지되어야 한다. TCP버퍼가 할당되어야 하고 TCP변수들이 클라이언트와 서버 양쪽에 유지해야한다. 이는 수 많은 다른 클라이언트의 요청을 동시에 서비스하는 웹서버에 심각한 부담을 줄 수있다.
각 객체는 2RTT가 필요, TCP연결설정에 1RTT, 객체를 요청하고 받는데 1RTT

->지속 연결에서는 서버는 응답을 보낸 후 TCP연결을 그대로 유지, 같은 클라이언트와 서버간의 이후 요청과 응ㄷ바은 같은 연결을 통해 보내진다.

이들 객체에 대한 요구는 진행중인 요구에대한 응답을 기다리지 않고 연속해서 만들어낼 수 있다.(파이프라이닝)

일반적으로 HTTP서버는 일정기간(타임아웃)사용되지 않으면 연결을 닫는다.

Sorbet

Sorbet is good...!

이전 포스트

코드스쿼드 1월 4주차 리뷰

다음 포스트