quic
QUIC("퀵"으로 발음)은 범용 목적의 전송 계층 통신 프로토콜로서, 구글의 짐 로스킨드(Jim Roskind)가
처음 설계하였고, 2012년 구현 및 적용
실험단계
TCP 가 아닌 UDP!
tcp의 헤더엔 거추장스럽고 필요없는 여러 옵션들이 많이 달려있다
반면에 udp엔 기본적인 기능만 있으니
TCP를 아무리 발전시켜도 TCP의 기본적 한계는 벗어날수 없다 생각하여
UDP로 방향을 틀었다고 한다.
특징으로는 3 핸드쉐이킹을 생략하고 바로 데이터를 보내는 특징이 있다.
또한 http 2.0 처럼 스트림을 병렬적으로 전송 가능하고, wifi를 이용하는 핸드폰 등 ip가 자주 바뀌는 기기들에게
빠른 대처가 가능하다는 장점이 있다.
http, ftp, telnet, ssh vs dns, dhcp, tftp, snmp, sip
유니캐스트는 정보를 전송하기 위한 프레임에 자신의 MAC 주소와 목적지의 MAC 주소를 첨부하여 전송
브로드캐스트 방식은 로컬 네트워크에 연결되어 있는 모든 시스템에게 프레임을 보내는 방식
멀티캐스트는 네트워크에 연결되어 있는 시스템 중 일부에게만 정보를 전송하는 것으로 특정 그룹에 속해 있는 시스템에게만 한 번에 정보를 전송할 수 있는 방법
라우터가 멀티캐스트를 지원해야만 사용 가능하다는 단점
멀티캐스트 전송이 지원되면 송신자는 여러 수신자에게 한 번에 메시지가 전송되도록 하여
데이터의 중복 전송으로 인한 네트워크 자원 낭비를 최소화할 수 있게 된다.
멀티캐스트 전송을 위해서는 헤더에 수신자의 주소 대신 수신자들이 참여하고 있는 그룹 주소를 표시하여 패킷을 전송한다.
웹 프락시 서버는 클라이언트의 입장에서 트랜잭션을 수행하는 중개인
HTTP 프락시 서버는 웹 서버이기도 하고 웹 클라이언트
개인 vs 공용 프락시
(대부분은 공용)
프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결한다.
게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다.
(서로 간의 트랙잭션을 완료할 수 있도록 해주는 변환기처럼 작동한다.)
장점
-
보안 개선 : 접근 차단, 제어 가능
-
성능 향상
-
비용 절약
-
HTTP 트래픽 모니터링 및 수정
-
웹 캐시
-
대리 프락시(Surrogate) : 어떤 프락시들은 웹 서버인 것처럼 위장한다. -> 분산 네트워크 용
-
트랜스코더 : 프락시 서버는 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정 할 수 있다.
-
컨텐츠 라우터 : 프락시 서버는 인터넷 트래픽 조건과 종류에 특정 웹 서버로 유도하는 컨텐츠 라우터
-
익명화 프락시(Anonymizer) : HTTP 메세지에서 신원을 식별할 수 있는 특성들을 제거함
(IP주소, From 헤더, Referer 헤더, 쿠키, URI 세션 아이디...)
클라이언트가 프락시 대신 서버로 요청을 보내면 요청의 URI가 달라진다.
서버로 보낼때와 달리 프락시로 요청을 보낼 때, 요청줄은 완전한 URI를 갖는다
(서버는 스킴, 호스트, 포트번호 생략이 가능하다)
프락시가 부상할 당시, 이미 너무 많은 서버가 배치되어 있었고 완전한 URI를 보낼 필요가 있었다.
\r\n이 아닌 \r\n\r\n이다......
까먹지 말자 ㅜ
reference
quic
https://ko.wikipedia.org/wiki/QUIC
https://musclebear.tistory.com/51
tcp udp
https://microchipdeveloper.com/tcpip:tcp-vs-udp
https://m.blog.naver.com/wnrjsxo/221250742423
프락시
https://velog.io/@honeysuckle/HTTP-%ED%94%84%EB%9D%BD%EC%8B%9CProxy%EC%9D%98-%EA%B0%9C%EB%85%90