IP (인터넷 프로토콜)
- 지정한 IP 주소(IP Address)에 데이터 전달 (출발/목적)
- 패킷(Packet)이라는 통신 단위로 데이터 전달
(클라이언트 패킷 전달 > 서버 패킷 전달을 통해 노드끼리 전달)
프로토콜이란,
데이터를 메시지를 주고 받는 양식과 규칙의 체계
HTTP, HTTPS, FTP, SFTP, SSH, SSL, SOAP, Telnet, ARP 등이 있음
IP 프로토콜의 한계
- 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
(패킷을 받을 서버가 이미 죽어있는 서버여도 전송이 진행됨, 서버에 잘 전송되고 있다가 노드가 갑자기 꺼져버리면 유실될 수 있고 유실되어도 모름 등)
- 비신뢰성 : 중간에 패킷이 사라진다면? 패킷이 순서대로 안 온다면?
(패킷이 길면 끊어서 보냄 1:Hello, 2:world!인데 도착은 2:world! 1:Hello,로 도착할 수 있음)
- 프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?
이러한 문제를 해결할 수 있는 것은!
TCP
: 전송 제어 프로토콜(Transmission Control Protocol)
- 연결지향 - TCP 3 way handshake -> 연결이 되어야 전송
(가상연결 : 물리적인 연결이 아니고 논리적인 연결 / 중간 노드들은 연결된지 모름) - 데이터 전달 보증 -> 상대가 메시지 못 받은 것을 알 수 있음
- 순서 보장
(1,2,3 순서로 보냈지만 1,3,2로 도착한 경우, 2번부터 다시 보내라는 명령)
=신뢰할 수 있는 프로토콜이며, 대부분 애플리케이션에서 사용
*인터넷 프로토콜 스택의 4계층
애플리케이션 계층 - HTTP, FTP
전송 계층 - TCP, UDP
인터넷 계층 - IP
네트워크 인터페이스 계층
이런 식으로
포트 번호, 순서 등 정보를 더 추가할 수 있어서
IP프로토콜의 문제를 해소할 수 있음
*TCP 3 way handshake 연결 과정
: 클라이언트가 1.SYN 전달 ➡️ 서버가 2.SYN+ACN 전달 ➡️ 클라이언트가 3.ACK 전달 ➡️ 연결이 다 되고 4.데이터 전송이 이루어짐
SYN : 접속 요청
ACK : 요청 수락 (3.ACK와 함께 데이터 전송 가능)
UDP
:사용자 데이터그램 프로토콜(User Datagram Protocol>
- 연결지향 ( TCP 3 way handshake X)
- 데이터 전달 보증, 순서 보장 X
- 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
- 결론적으로, IP와 거의 같고 +PORT, 체크섬 정도만 추가한 수준 / 애플리케이션에서 추가 작업 필요
PORT
한번에 둘 이상 연결해야 해서 패킷이 여러 개라면,
같은 IP 내에서 프로세스 구분하는 것이 필요함 > PORT
ex, 게임 서버에 연결하려면 200.200.200.2 IP의 11220 포트에 연결로 포트를 전송
서버에서 결과를 만들어서 응답을 할 때는 100.100.100.1 IP의 10010 포트로 전송
(패킷 보낼 때 이미 IP와 출발지 포트 번호 등이 다 포함되어 있기 때문)
0~65535 할당 가능하지만, 0~1023은 잘 알려진 포트라 사용하지 않는 것이 좋음
FTP : 20,21
TELNET : 23
HTTP : 80
HTTPS : 443
DNS
: 도메인 네임 시스템 (Domain Name System)
IP가 길고, 변경될 수 있기 때문에 접근에 혼란이 생길 수 있음
(클라이언트가 서버에 요청하기 전에, DNS 서버에 도메인명보내고 IP주소를 요청 > DNS 서버에서 IP주소 응답 > 서버로 접속)
URI
Uniform : 리소스 식별하는 통일된 방식
Resource : URI로 식별할 수 있는 모든 자원
Identifier : 구분하는데 필요한 정보
로케이터(locator, URL) / 이름(name, URN) 또는 둘 다 추가로 분류될 수 있음
URL : 리소스가 있는 위치 지정
URN : 리소스에 이름 부여
scheme://[userinfo@] host [:port] [/path] [?query] [#fragment]
1. 주로 프로토콜 사용
2. URL에 사용자 정보 포함해서 인증, 거의 사용 x
3. 호스트명
4. 포트는 생략 가능
5. 리소스 경로(path), 계층적 구조
6. key=value형태 / ?로 시작, &로 추가 가능 / 숫자를 넣어도 다 문자로 넘어가기 때문에 query string으로 불리기도 함
7. 거의 사용x, html 내부 북마크 등에 사용 되며 서버에 전송되는 정보는 아님
http://www.google.com:443/search?q=hello&hl=ko
도착받은 서버에서는 TCP/IP 껍데기는 버리고, HTTP 메시지 요청에 대한 응답 메시지를 만들고 그 위에 다시 TCP/IP패킷을 씌워 전송
응답받은 웹 브라우저가 HTML 렌더링을 하여 결과값을 보는것
*http 요청 메시지 예시
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
*http 응답 메시지 예시
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<bady>..</body>
</html>
HTTP
:HyperText Transfer Protocol
이제는 모든 것을 담아서 http 프로콜로 전송이 가능
(HTML, TEXT, image, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터 전송 가능)
- 클라이언트 서버 구조
- 무상태 프로토콜(스테이스리스), 비연결성
- HTTP 메시지 (송수신 모두)
- 단순하고 ,확장 가능
특징1. 클라이언트 서버 구조
: 요청(Request) 응답(Reponse) 구조
: 클라이언트는 서버에 요청, 응답 대기 / 서버가 요청에 대한 결과를 만들어 응답
특징2. 무상태 프로토콜(스테이스리스 Stateless)
: 서버가 클라이언트 상태를 보존하지 않음
(상태유지 statefull은 서버가 클라이언트의 이전 상태를 보존하기 때문에 중간에 서버를 바꿀수 없고, 중간에 바뀔 때마다 상태 정보를 다른 서버에 미리 알려줘야 함 / 무상태는 중간에 서버가 변경되어도 가능 ⭐️응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능
예를 들어, 클라이언트A가 노트북, 2개 결제 요청하면 서버는 상태를 보존하지 않고 바로 응답 가능하고, 이는 서버B에 가도 응답이 가능함)
*stateless의 한계
모든 것을 무상태로 설계할 수 는 없음
무상태 - 로그인이 필요없는 단순한 소개 화면
상태 유지 - 로그인한 사용자의 경우 로그인 상태를 서버에 유지 / 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 유지 / 상태 유지는 최소한만 사용해야 함너무 많은 데이터를 전송하게 됨
특징3. 비연결성
HTTP는 기본적으로 연결을 유지하지 않음빠른 속도로 응답수천명이 사용해도 실제 서버에서 동시 처리하는 요청은 수십개 이하로 적음서버 자원을 효율적으로 사용
*단점
TCP/IP 연결을 새로 맺어야 하고, 그때 3 way handshake 시간 추가
웹 브라우저로 사이트 요청하면 html 뿐 아니라 자바스크립트, css 등 많은 자원 함께 다운로드됨지금은 HTTP 지속 연결로 문제 해결 Persistent Connections) HTTP/2와/3는 최적화됨
이런 식으로 모든 서버를 계속 유지하지 않고,
응답보내면 연결 끊어서 최소한의 자원 유지
*기반 프로토콜
TCP : HTTP/1.1 , HTTP/2
UDP : HTTP/3
(TPC는 3핸드셰이크 때문에 속도가 느리고, 데이터도 많아서 UDP 프로토콜 위에 애플리케이션에서 성능 최적화하도록 설계해서 나온 것이 HTTP/3 & 주로 1.1 사용하지만, /2와 /3도 급속도로 점점 증가)
⭐️스테이스리스는 서버 개발자들이 어려워하는 업무
선착순 이벤트나 학과 수업처럼 같은 시간에 수만명이 동시 요청해야 하는 업무처럼 *대용량 트래픽이 발생할 때는 최대한 스테이스리스하도록 설계해야 함*
그래서 정적페이지로 시작(순수한 html 하나만 딱)해서 약간 시간을 끌고 이벤트 참여를 누르게끔 유도
HTML 메시지
[요청 메시지 시작 라인]
요청 메시지 - HTTP 메서드
종류 - GET(리소스 조회), POST(요청 내역 처리), PUT, DELETE.....
요청 메시지 - 요청 대상
absolute-path[?query] (절대경로[?쿼리])
절대경로는 /로 시작함
요청 메시지 - HTTP 버전
HTTP Version 넣음
[응답 메시지 시작 라인]
HTTP 버전
HTTP 상태 코드 : 요청 성공/실패 (200:성공, 400:클라이언트 요청 오류, 500:서버 내부 오류)
이유 문구 : 짧은 상태 코드 설명 (200 OK)
[응답 메시지 헤더]
header-field = field-name ":" OWS field-value OWS (OWS : 띄어쓰기 허용)
필드 네임은 대소문자 구분 없음
*헤더 용도
- http 전송에 필요한 모든 부가 정보
- 메시지 바디의 내용, 크기, 압축 유무, 인증, 요청 클라이언트 브라우저 정보, 캐시 관리 정보 등
- 표준 헤드 많음
- 필요시 임의의 헤더 추가 가능 (helloworld: hihi)
[응답 메시지 메시지 바디]
실제 전송할 데이터 (HTML 문서, 이미지, 영상, JASON 등 byte로 표현할 수 있는 모든 데이터 전송)
JSON이란,
JavaScript Object Notation의 약자
데이터를 저장 및 교환(전송)할 때 사용하는 텍스트 기반 데이터 형식
텍스트 기반이라 인간도 쉽게 읽음
이전에는 XML이 있었는데 헤더와 태그 등 여러 요소로 가독성 저하&용량 문제의 단점
{ } 안은 속성명이 있는 객체
[ ] 안은 순서가 있는 배열, 객체 안에 객체 포함 가능
값을 ','로 나열
JSON은 null, number, string, array, object, boolean 사용 가능
인프런에 김영한님 HTTP 기본 강의로 공부했습니다 :)
'Study > Dev' 카테고리의 다른 글
| [IT기획자준비]HTTP에 대해 알아보자. 3/3 (헤더ㅣ쿠키ㅣ캐시) (0) | 2025.01.06 |
|---|---|
| [IT기획자준비] HTTP 상태코드 종류? (0) | 2025.01.06 |
| [IT기획자준비]HTTP에 대해 알아보자. (2/3) (1) | 2025.01.02 |
| [IT기획자준비] html에 대해 알아보자. (2/2) (2) | 2024.12.26 |
| [IT기획자준비] html에 대해 알아보자. (1/2) (3) | 2024.12.20 |