network edge: 컴퓨터network core: 라우터network link: 무선 링크, 유선 링크..
웹 브라우저: 네트워크 기능이 있는 프로세스 어플리케이션 레이어는 아래의 계층들에 대해서 전혀 신경쓸 필요가 없다. 어플리케이션 레이어는 client-server architecture이다. server 24시간 켜져있어야 한다. 고정된 IP 주소를 가져야한다. (
프로세스들끼리의 통신.즉 클라이언트 프로세스와 서버 프로세스 간의 통신.네트워크에서도 OS에서 제공하는 인터페이스(API)를 활용.TCP 소켓/UDP 소켓 둘 중 한 방식을 이용.TCP Serversocket() -> 소켓을 만듦bind() -> 어떤 포트에 연결할지l
Multiplexing(Sender 컴퓨터): 여러 소켓에서 전달받은 데이터를 전송 계층에서 (어플리케이션 계층 -> 전송 계층)Demultiplexing(Receiver 컴퓨터): 세그먼트를 받아서 거기에서 데이터를 꺼내서 알맞은 소켓(프로세스)에 전달해주는 것 (전
이전에 가정한 상황은 한 번에 데이터를 하나 보내고 ACK/NAK가 올 때까지 기다리는 상황인데 이렇게 하면 네트워크 효율이 너무 떨어짐. 따라서 한번에 많이 보내는 프로토콜이 필요한 번에 많은 패킷을 보낼 건데, 그 양을 window size라고 함0, 1, 2, 3
한 쌍의 프로세스 간의 통신(엄격하게 말하면 소켓 한 쌍끼리의 통신) point-to-point유실되지 않으면서 순서대로 가지고 감pipelined -> window 크기만큼은 ACK랑 상관없이 쏟아부음 -> 재전송도 window 크기 단위로 -> 그래서 receive
네트워크 계층의 프로토콜은 IP.라우터에는 네트워크까지의 계층이 있음.라우터에서 하는 일 두 가지1\. Forwarding2\. Routing패킷의 목적지(header에 있음)를 확인 + 목적지로 가기 위해 어떤 경로로 보내야할지를 forwarding table을 보고
목적지까지 최소 비용의 경로를 찾는 것이 목표forwarding table의 entry를 채워야함1) 네트워크 상황을 다 아는 경우 : Link-State Algorithm=> 모든 노드들이 자기의 링크 정보를 네트워크에 브로드캐스트로 뿌려둬야함 => 전체 그래프를 알
패킷은 시그널(파장)로 매체(broadcast medium)를 통해 게이트웨이 전달됨.근데 시그널이라는 건 다 퍼지기 때문에 게이트웨이 라우터에 전하고자 하는 얘기가 다른 링크에 붙은 라우터들에도 퍼짐 -> collision -> 게이트웨이 라우터가 해독할수 없게 됨링
같은 서브넷에 속한(라우터를 거치지 않고 매개체를 통해 접근 가능함) 호스트들의 집합.type: 데이터가 어떤 상위 레이어의 프로토콜인지. 보통 IP Protocol이라고 적혀있음.CRC: 에러 체킹에 사용source address: MAC addressphysical
요즘은 위와 같이 switch를 이용해서 star형으로 토폴로지를 구성함.버스형에서 전체가 collision domain인 것과 달리 성형은 collision domain이 분리되어 있어서, 다른 도메인에 있는 애들은 동시에 데이터를 보낼 수 있음.switch는 맥 주
단락 번호는 책 내용 위치 참고를 위한 것입니다HTTP는 웹에서 전송되는 객체 각각에 MIME(Multipurpose Internet Mail Extension) 타입이라는 데이터 포맷 라벨을 붙인다.MIME은 이름에서 알 수 있듯 이메일에서 사용되던 것으로, HTTP
URL은 HTTP 프로토콜 외의 다른 프로토콜에서도 사용된다ex)president@whitehouse.gov (이메일 주소)ftp://ftp.lots-o-books.com/pub/complete-price-list.xls (FTP(File Transfer Protoco
인바운드 : 클라이언트 > 서버 방향 (서버 방향) 아웃바운드 : 서버 > 클라이언트 방향 (사용자 에이전트 방향) 업스트림 : 메시지의 발송자 다운스트림 : 메시지의 수신자요청 메시지의 형식<메서드> <요청 URL> <버전> <헤더> <엔티
4.1.2 TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송된다 HTTP는 그림과 같이 'IP, TCP, HTTP'로 구성된 '프로토콜 스택'에서 최상위 계층이다. 그리고 여기에 보안 계층인 TLS(SSL)이 추가된 것이 HTTPS이다. TCP는 세그먼트라
'웹 서버'라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비 양쪽을 다 가리킨다 웹 서버의 역할1\. HTTP 프로토콜을 구현2\. 웹 리소스를 관리3\. 웹 서버 관리 기능을 제공운영체제의 역할1\. 컴퓨터 시스템의 하드웨어를 관리2\. TCP/IP 네
프록시클라이언트와 서버 사이의 중개자.클라이언트 서버 사이에서 요청, 응답을 건네준다.서로 다른 HTTP 버전을 중개하는 경우 약간의 프로토콜 변환을 하기도 한다.사용 목적: 네트워크 캐싱, 특정 웹 사이트 액세스 방지, 보안 방화벽 (보안 강화), 웹 캐시 문서 접근
gRPC는 HTTP/2.0을 기반으로 하는데,HTTP/2.0과 1.1은 모두 long lived connection이라는 공통점이 있지만, HTTP/2.0는 1.1과는 달리 multiplexing 기술을 connection에 적용한다는 차이점이 있다.HTTP/1.1은
이번 장에서 이야기하는 이야기하는 캐시는 웹 캐시(HTTP Cache)이다.웹 캐시의 종류1\. 브라우저 캐시 : 사용자 컴퓨터의 로컬 저장소에 이전 방문한 웹페이지의 정적 자원을 저장해 사용한다.2\. 프록시 웹 캐시 : 클라이언트와 origin 서버 간의 프록시\-
게이트웨이는 HTTP 트래픽을 다른 프로토콜로 자동 변환 \-> 원 서버의 부하를 줄여주지만, 게이트웨이와 원 서버 사이에 있는 네트워크가 안전한지 확실히 확인하고 써야함애플리케이션 서버도 게이트웨이의 일종. 애플리케이션 서버는 게이트웨이와 목적지 서버를 한 개의 서버
웹 관리자는 웹 사이트의 모든 콘텐츠에 대한 차단 규칙을 종합적으로 기술한 robots.txt 파일을 생성할 책임이 있다.\-> 없다면 로봇은 제약없이 사이트에 접근한다.\-> 401 혹은 403 권한 없음으로 응답하면 로봇은 해당 사이트로의 접근을 아예 해서는 안된다
HTTP/1.1은 구현의 단순성과 접근성에 주안점을 둠\-> 성능이 희생됨 (ex. 응답을 받아야만 그 다음 요청을 보낼 수 있음)\-> 이런 문제를 해결하기 위해 병렬 커넥션(커넥션을 동시에 여러개 맺는건데, 근본적인 해결책은 아님), 파이프라인 커넥션(사용되지 않음
서버에서 클라이언트 IP를 알 수 있는 방법nginx 같은 웹 서버에서는 기본적으로 remote_addr 헤더를 통해 클라이언트 IP를 얻을 수 있음그러나 nginx에 도달하기 전에 프록시, 로드밸런서 등을 거치는 경우에는 이러한 클라이언트 IP가 프록시의 IP로 변경
인증은 내가 누구인지 증명하는 것.HTTP에는 기본 인증과 다이제스트 인증이 있음<기본 인증 예시>(a) 요청을 보냄(b) 서버가 사용자에게 인증요구를 보냄. 401 Unauthorized + WWW-Authenticate 헤더(어디서 어떻게 인증할지 설명)(c)
비밀번호를 그대로 보내지 않음 -> 비밀번호를 비가역적으로 섞은 지문(fingerprint) 혹은 요약(digest)를 보냄 재전송 방지를 위한 난스 이용 -> 난스를 비밀번호에 섞으면 난스가 바뀔 때마다 요약도 바뀌게 만들어줌
HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작이 보안 계층은 Secure Socket Layer(SSL) 혹은 Transport Layer Security(TLS)를 이용해 구현된다 SSL, HTTPS에는 암호 인코딩 기법이 적용된다
HTTP는 다음을 보장객체는 올바르게 식별됨 (Content-Type, Content-Language)객체는 올바르게 압축이 풀림(Content-Length, Content-Encoding)객체는 항상 최신(엔티티 검사기, 캐시 만료 제어)사용자의 요구를 만족(Acce
스위치(허브)가 아닌 서버 레벨에서의 로드 밸런싱(부하 분산). DNAT(Destination Network Address Translation) 방식을 이용해 하나의 VIP에 여러 서버들이 붙어있을 수 있음예를 들어, nginx g/w의 vip는 하나이지만 실제 서버