IT STUDY LOG
[네트워크 기초] 소켓, 포트, HTTP 버전 조사 및 발표 준비 본문
# 조사 및 발표
발표 주제 1
소켓과 포트의 특징을 작성하고, 그 차이점을 설명하세요.
소켓
- 응용 계층과 전송 계층 간의 소프트웨어 Interface
- 데이터 통신이란 결국 호스트와 호스트 간의 데이터를 주고받는 행위
- 데이터 통신을 위해 응용 계층(사용자가 네트워크에 접근할 수 있는 인터페이스를 담당하는 계층)의 네트워크 서버/클라이언트 프로그램은 역할에 따라 프로세스를 생성
- 주로 백그라운드 프로그램인 데몬이 메모리에 상주하며 사용자 요청을 기다리며 프로세스를 리스닝
- 서버와 클라이언트 각 각 프로세스가 연결되어야 네트워크 통신을 통해 데이터 송수신이 가능한데, 이 연결 창구 역할을 소켓이 수행
- 소켓은 프로그래머가 네트워크 통신을 위해 송신자와 수신자 간의 연결을 설정하고, 데이터를 전송하고, 연결을 종료하는 등의 작업을 수행할 수 있게 해 줌
소켓의 전송 타입
스트림 방식
- TCP에 사용되는 방식
- 연결지향 방식으로 연결을 확립하고 데이터를 전송
데이터그램 방식
- UDP에 사용되는 방식
- 비연결지향 방식으로 데이터를 전송
포트
- 네트워크에서 프로세스가 통신을 하기 위해 할당받는 번호로, 프로세스를 구분하는 식별자
- 한 개의 포트는 한 프로세스에만 할당이 가능
- 포트는 소켓을 통해 들어오는 데이터가 어떤 프로세스로 전달되어야 하는지 지정하고, 데이터 도착할 목적지를 결정하는 데 사용
- 포트는 프로세스를 구분하는 식별자이고, 소켓은 그 포트의 프로세스로 연결하기 위한 연결 부분이므로 하나의 포트에 여러 소켓이 생성 가능
포트의 분류 방식
사용 목적에 따른 포트 범위
- well-known port(0 ~ 1023) : 잘 알려진 서비스에 예약된 포트로 ftp, http, telnet 등의 포트가 이에 해당
- registered port(1024 ~ 49151) : 제조사(vendor)가 iana에 용도를 등록해 사용하는 포트로 대표적으로 DBMS에서 사용하는 포트가 이에 해당
- dynamic port(49152 ~ 65535) : 동적으로 사용하는 포트로 일반적으로 클라이언트 포트로 사용
사용 권한에 따른 포트 범위
- previleged port(0 ~ 1023) : 관리자 권한(root, administrator)으로 사용 가능한 포트
- unprevileged port(1024 ~ 65535) : 일반 사용자 권한으로 사용 가능한 포트
발표 주제 2
HTTP 버전별 특징과 차이점을 설명하세요.
HTTP/0.9 - 원-라인 프로토콜
- 요청은 단일 라인으로 구성
- 메서드는 GET만 지원
- HTTP 헤더가 없어 HTML 파일만이 전송 가능
- 응답 상태, 오류 코드도 존재하지 않아 문제 발생 시 수신 측에서 처리할 수 있도록 파일 내부에 설명 첨부
- 요청과 응답 방식
// 요청
GET /mypage.html
// 응답
<HTML>
A very simple HTML page
</HTML>
HTTP/1.0 - 확장성 만들기
- 1991년~1995년간 도입되었으나 공식적인 표준은 아님
- 일반적인 실제 내용을 설명하는 문서는 1996년 RFC 1945에 공개
- 요청 : 버전 정보전송되기 시작 (ex) GET /URL HTTP/1.0
- 응답 : 상태 코드가 전송되어 브라우저가 성공, 실패 여부 판별 가능
- HTTP 헤더가 요청, 응답 모두에 도입되어 메타데이터 전송 허용해 프로토콜을 유연하고 확장 가능하도록 만듦
- 헤더를 도입하며 Content-Type을 구분할 수 있게 되어 HTML 외의 다른 파일 전송이 가능
- 요청과 응답 방식
// 요청
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
// 응답
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
HTTP/1.1 - 표준 프로토콜
- 1997년 1월에 RFC 2068 공개
- 많은 개선 사항을 도입
> 커넥션 재사용이 가능
> 파이프라이닝 추가로 첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청 전송이 가능
> 청크 된 응답 지원
> 추가적인 캐시 제어 메커니즘 도입
> 언어, 인코딩, 타입을 포함한 콘텐츠 협상 도입으로 클라이언트-서버 간 교환에 적합한 콘텐츠에 대한 동의가 가능
> host 헤더 도입으로 동일 IP 주소에 다른 도메인을 호스트 가능
cf. 가상 호스팅 기술을 사용해 하나의 물리적인 서버에 여러 개의 도메인을 호스팅하는 방식으로, 서버의 IP 주소를 공유하면서도 각 도메인은 독립적으로 동작
(ex) 동일한 IP 주소에 "domain1.com"과 "domain2.com"이라는 두 개의 도메인이 호스팅되어 있을 경우, 클라이언트가 "domain1.com"으로 접속을 시도하면, 서버는 도메인 이름을 보고 "domain1.com"에 해당하는 웹 페이지를 반환하고 "domain2.com"으로 접속을 시도하면, 서버는 "domain2.com"에 해당하는 웹 페이지를 반환
가상 호스팅은 서버의 리소스를 효율적으로 활용하고, 도메인 간의 충돌을 방지하는 이점 존재
웹 서버의 설정이나 가상 호스팅 소프트웨어를 통해 도메인별로 별도의 디렉토리나 설정을 할당하고, 도메인 간에 서로 격리된 환경을 제공
- 15년간 유지
- SSL/TLS를 통해 보안 전송 가능
- RESTful API나 웹소켓, Server-sent events 기술 등 복잡한 애플리케이션을 위해 사용 가능
- CORS 등 웹 보안 모델 완화 가능
- 요청과 응답
// 요청1
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
// 응답1
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
// 요청2
GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
// 응답2
200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache
(image content of 3077 bytes)
HTTP/2 - 더 나은 성능을 위한 프로토콜
- 웹 페이지가 복잡해지며 데이터의 양과 크기가 점점 증가
- 요청의 순서가 중요해짐
- 구글의 SPDY 프로토콜(클라이언트-서버 간 데이터 교환을 빠르게 한 수단)이 HTTP/2 프로토콜의 기초가 됨(응답성 증가, 데이터 중복 문제 해결)
- HTTP/1.1과 호환되며 클라이언트와 서버가 HTTP 1.1, 2.0 혹은 다른 비 HTTP 프로토콜 사용을 협상할 수 있는 메커니즘 구현
- HTTP/1.1과의 차이
> HTTP/2는 텍스트 프로토콜보다는 이진 프로토콜에 가까움
> 병렬 요청이 동일한 커넥션에서 이루어질 수 있는 다중화 프로토콜로 순서를 제거하고 HTTP/1.x의 제약을 방지
> 전송된 데이터의 중복과 오버헤드를 제거하고 연속된 요청 사이 유사한 내용의 헤더를 압축
> 사전에 서버가 클라이언트 캐시를 서버 푸시를 통해 필요할 데이터를 채우도록 함
- 트래픽이 많은 웹 사이트에 적용하면 효과적
차세대-HTTP/2로 진화
- Client Hints 도입으로 브라우저, 클라이언트가 요구사항이나 서버 하드웨어 제약사항에 관한 정보를 사전에 미리 주고받는 것이 가능
- cookie 내에 보안 접두사 도입을 해 쿠키가 변경되지 않았음을 보장
HTTP/3 - HTTP Over QUIC
- HTTP 이전 버전들과 동일하게 요청 메서드, 상태 코드, 메시지 필드가 적용되나 TCP/TLS 대신 QUIC을 사용
- QUIC은 Quick UDP Internet Connection으로 UDP 상에 구현된 실험적인 다중 전송 프로토콜로 TCP 및 웹 애플리케이션 전송을 개선하기 위한 방법을 위해 Google에서 실험적으로 개발한 프로토콜
- QUIC을 사용하는 이유는 HTTP/2의 헤드 오브 라인 블로킹이라는 문제를 해결하기 위함
> HTTP/2에서는 헤더 데이터를 압축하여 전송하는데, 이 압축된 헤더 데이터를 해독하기 위해 전체 헤더 블록을 수신해야 함
> 따라서 한 개의 헤더 블록이 완전히 수신되기 전까지는 해당 헤더 블록에 속한 다른 헤더들도 처리되지 않고 블로킹되는 현상이 발생
> 헤더 데이터를 기다리는 동안 다른 리소스 전송 지연과 성능 저하가 유발
- 2020년 10월 기준으로 W3 Techs에 따르면 10,000,000개 웹사이트 중 8%가 HTTP/3을 지원
# References
정보보안기사 실기, 도서출판 탑스팟, 정일영·강재순·조현준 공저
챗 GPT
👩💻 프로세스 / 데몬 / 서비스 차이 한방 정리
프로세스 (Process) 프로세스는 메모리에 적재되어 CPU에 의해 실행되는 컴퓨터 프로그램을 지칭한다. 각 프로세스는 고유한 프로세스 ID(PID)를 가지며, 운영체제는 프로세스 간의 자원 공유를 관리
inpa.tistory.com
'devops bootcamp 4 > assignment log' 카테고리의 다른 글
| [Infrastructure as Code] IaC 조사 및 발표 준비 (0) | 2023.05.12 |
|---|---|
| [네트워크 기초] HTTP 헤더 분석, ifconfig 명령어 조사 및 발표 준비 (0) | 2023.04.07 |
| [데이터베이스] 조사 및 발표 준비 (0) | 2023.03.29 |
| [HTTP] REST API 모범 사례 조사 및 발표 준비 (0) | 2023.03.23 |
| [HTTP] HTTP 구조 조사 및 발표 준비 (0) | 2023.03.22 |
