인터넷 네트워크
IP(인터넷 프로토콜)
지정한 IP 주소(IP Address)에 데이터 전달
패킷이라는 통신 단위로 데이터 전달
IP 프로토콜의 한계
비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성 : 패킷이 중간에 사라지거나 , 패킷이 순서대로 도착하지 않을 수도 있음.
인터넷 프로토콜 스택의 4계층
애플리케이션 계층 - HTTP , FTP
전송 계층- TCP , UDP
인터넷 계층-IP
네트워크 인터페이스 계층
TCP(전송 제어 프로토콜)
연결지향 - TCP 3 way handshake
데이터 전달 보증
순서 보장
신뢰할 수 있는 프로토콜
연결지향 - TCP 3 way handshake
클라이언트 - 서버 사이에서 3단계로
1.SYN ,
2.SYN+ACK
3.ACK 로 접속 요청 , 요청 수락을 보냄
순서 보장
클라이언트 - 서버 사이 에서 패킷1,패킷2,패킷3 순서로 보냈다고 했을때 패킷1,패킷3,패킷2 순서로 도착한 경우
패킷2 부터 다시 보내달라함.
UDP(사용자 데이터그램 프로토콜)
연결지향 X
데이터 전달 보증 X
순서 보장 X
단순하고 빠름
IP와 비슷하다. UDP는 PORT와 체크섬이 있음.
PORT
같은 IP 내에서 프로세스를 구분한다.
클라이언트(100.100.100.1) 서버(200.200.200.2)
게임(8090) 게임(11220)
화상통화(21000) 화상통화(32202)
웹 브라우저(10010) 서버(200.200.200.3)
웹브라우저(80)
DNS(도메인 네임 시스템)
도메인 명을 IP 주소로 변환 한다.
클라이언트가 DNS 서버에 도메인 명으로 요청 하면 IP 주소를 응답 해주고 그 IP 주소로 서버에 접속한다.
URI
Uniform : 리소스 식별하는 통일된 방식
Resource : 자원, URI로 식별할 수 있는 모든 것
Identifier : 다른 항목과 구분하는데 필요한 정보
URL - Locator: 리소스가 있는 위치를 지정
URN - Name: 리소스에 이름을 부여
ex: URL : foo://example.com:8042/over/there?name=ferret#nose
ex: URN : urn:example:animal:ferret:nose
URL 전체 문법
scheme://[userinfo@]host[:port][/path][?query][#fragment]
https://www.google.com:443/search?q=hello&hl=ko
프로토콜(https)
호스트명(www.google.com)
포트 번호(443)
패스(/search)
쿼리 파라미터(q=hello&hl=ko)
URL scheme
주로 프로토콜 사용
프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
ex) http, https, ftp 등등
URL userinfo
URL에 사용자정보를 포함해서 인증
거의 사용하지 않음
URL host
호스트명
도메인명 또는 IP 주소를 직접 사용가능
URL PORT
접속포트
일반적으로는 생략, 생략시 http는 80 , https는 443
URP path
리소스 경로(path), 계층적 구조
ex) /home/file1.jpg
ex) /members
ex) /member/100
URL query
key = value 형태
? 로 시작 , & 로 추가 가능 ex) ?keyA=valueA&keyB=valueB
URL fragment
html 내부 북마크 등에 사용
서버에 전송하는 정보 아님
HTTP(Hyper Text Transfer Protocol)
HTTP 메시지에 모든 것을 전송
HTML, TXT , IMAGE , 음성, 영상, 파일 , JSON , XML
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
현재는 HTTP/1.1 가장 많이 사용하고 있음
HTTP/2 : 성능 개선
HTTP/3 : TCP 대신 UDP 사용 , 성능 개선
HTTP 특징
클라이언트 서버 구조
무상태 프로토콜(stateless0, 비연결성
HTTP 메시지
단순함, 확장 가능
클라이언트 서버 구조
Request , Response 구조
클라이언트는 서버에 요청을 보내고 , 응답을 대기
서버가 요청에 대한 결과를 만들어서 응답
무상태 프로토콜
서버가 클라이언트의 상태를 보존 x
장점: 서버 확장성이 높음
단점: 클라이언트가 추가 데이터 전송해야함
비 연결성
HTTP는 기본이 연결을 유지하는 않는 모델
서버 자원을 효율적으로 사용할 수 있음
TCP/IP 연결을 새로 맺어야함 - 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트 , css , 추가 이미지 등 수많은 자원이 함께 다운로드
지금은 HTTP 지속 연결로 문제 해결
HTTP 메시지
HTTP 메시지에 모든것을 전송한다.
HTML , TEXT, IMAGE , 음성 , 영상 , 파일 , JSON , XML 등등
| GET /search?q=hello&hl=ko HTTP/1.1 |
| Host: www.google.com |
ex) HTTP 요청 메시지
| HTTP/1.1 200 OK |
| Content-Type: text/html;charset=UTF-8 Content-Length: 3423 |
| <html> <body>...</body> </html> |
ex) HTTP 응답 메시지
| start - line 시작 라인 |
| hearder 헤더 |
| empty line 공백 라인(CRLF) |
| message body |
HTTP 메시지 구조
시작 라인 요청 메시지
| GET /search?q=hello&hl=ko HTTP/1.1 |
| Host: www.google.com |
start - line = request-line / status - line
request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
ex) GET /search?q=hello&hl=ko HTTP/1.1
HTTP 메소드 ( GET)
요청 대상 (/search?q=hello&hl=ko)
HTTP Version
요청 메시지 - HTTP 메소드
종류: GET , POST , PUT , DELETE
서버가 수행해야할 동작 지정
GET : 리소스 조회
POST : 요청 내역 처리
요청 메시지 - 요청 대상
절대경로="/"로 시작하는 경로
요청 메시지 - HTTP 버전
HTTP Version
시작 라인 응답 메시지
| HTTP/1.1 200 OK |
| Content-Type: text/html;charset=UTF-8 Content-Length: 3423 |
| <html> <body>...</body> </html> |
start - line = request-line / status - line
status-line = HTTP-version SP status-code SP reason-phrase CRLF
HTTP 상태 코드 : 요청 성공 , 실패를 나타냄
200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류
HTTP 헤더
HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보
HTTP 메시지 바디
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP 메소드
종류
GET: 리소스 조회
POST: 요청 데이터처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제
기타 메소드
HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명
CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
GET
리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
POST
요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
POST 정리
1. 새 리소스 생성
서버가 아직 식별하지 않은 새 리소스 생성
2. 요청 데이터 처리
단순히 데이터를 생성하거나 , 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
3. 다른 메소드로 처리하기 애매한 경우
EX) JSON으로 조회 데이터를 넘겨야 하는데, GET 메소드를 사용하기 어려운 경우
애매하면 POST 사용
PUT
리소스를 대체
리소스가 있으면 대체, 리소스가 없으면 생성
클라이언트가 리소스 위치를 알고 URI 지정
PATCH
리소스 부분 변경
DELETE
리소스 제거
HTTP 메소드의 속성
안전(Safe)
호출해도 리소스를 변경하지 않는다.
멱등(Idempotent)
한 번 호출하든 두번 호출하든 100번 호출하든 결과가 똑같다.
GET: 한번 조회하든 , 두번 조회하든 결과가 똑같다.
PUT: 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종 결과는 같다.
DELETE:결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
POST: 멱등이 아니다, 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.
캐시가능
GET, HEAD, POST, PATCH 캐시 가능
실제로는 GET,HEAD 정도만 캐시로 사용
출처: https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC
'HTTP' 카테고리의 다른 글
| 김영한 HTTP 웹 기본 지식 3일차 (0) | 2021.12.20 |
|---|---|
| 김영한 HTTP 웹 기본 지식 2일차 (0) | 2021.12.17 |
