1. 네트워크란?
   1. 패킷 스위치 방식으로 연결된 컴퓨터들
   2. 사용자들이 자기가 보낸 데이터를 패킷이라는 어떤 작은 단위로 쪼개서 전송함
   3. 네트워크 자원들 라우터 라든지 패킷 단위로 자연스럽게 타임쉐어링 방식으로 공유한다
   4. 예약을 하지 않고 사용한다 === 패킷스위치 방식
      1. 패킷 스위칭 방식의 문제점
         1. 라우터에서 발생하는 딜레이와 패킷 로스
   5. 딜레이 = 라우터를 공유하기 때문에 생기는 문제
      1. 큐잉딜레이: 큐에서 라우터를 빠져나가기 전까지 기다려야함
      2. 패킷 로스: 라우터에서 큐에 들어가서 자리를 기다려야되는데, 사람이 많이 몰리게되면 언젠가는 자리가 모자를 수 밖에 없거든요. 그럼 유실되는 거였어요.
   6. 라우터에서 지연이 발생할때, 딜레이가 발생하는 것은 필연적
      1. 프로세싱 딜레이: (라우터가 패킷에 들어와서 헤더를 검색해서 어디로 나갈지 계산하는 시간)
      2. 큐잉 딜레이: 어느 방향으로 갈지 정했으면 그 방향에 있는 큐에 집어넣어서 대기하는 큐잉 딜레이
      3. 트랜스미션 딜레이: 큐 젤 앞에 나와서 패킷 전체가 온전하게 링크로 뿜어져나가는데 걸리는 시간
      4. 프로포게이션 딜레이: 링크를 타고 다음 라우터까지 전달하는데까지 걸리는 빛의 속도 * 거리인 물리적 딜레이
2. HTTP
   1. 기능 / 기술
      1. 웹 캐시, 웹 프록시
      2. 보통의 리소스는 웹 서버쪽에 존재해서 들고있다가 사용자가 요청했을 때 사용자에게 전달해준다.
      3. 웹 프록시: 이걸 쓰면 서버는 부하가 적어서 좋고 네트워크 사용자한테는 밖으로 부하가 안나가서 돈이 안 듦.
      4. 단, 일관성 문제가 발생할 수 있다.
      5. 그래서 이 문제를 위해서 예시만 보면 웹 캐시 좋네.
      6. 이렇게 까지만 알고 넘어가면 일반인이고, 웹캐시가 있음으로 해서 구체적으로 어떤 장점이 있는지 수치화해서 판단할 수 있어야겠죠.
      7. 힙 레이션는 어떻게 되고, 링크 band width은 어떤 상태에서 어떻게 되는지 계산해서 있을 때와 없을 때가 얼마 만큼 차이가 나는지 그런 것들.
      8. 캐시에서 발생하는 업데이트가 됐는지 아웃데이트 됐는지에 대한 일관성문제
      9. 이런건 conditional get이라는 테크닉 사용해서 처리를 한다고 했어요. http 헤더 중에 if modified since라는 필드가 있어서 이 필드를 사용해서 날짜를 확인해서 보내면 그 날짜 이후로 리소스가 수정되었는지 확인해서 수정되지 않았다면 안보내줘.
      10. 예를 들면 예가 2에서 3기가 짜리 데이터를 갖고 있었다고 생각해봐. 캐시 없었으면 3기가 짜리 또 보내줬을 거 아냐 얼마나 오버헤드가 커요. 데이타 없이 오기 때문에 40바이트밖에 안돼요. 엄청난 테크닉, 이 테크닉 어디서 쓰이냐. 웹 프록시에서 쓰이겠죠. 얘가 여기 가끔씩 이렇게 if modified since이렇게 해보겠지. 어쨌든 이거 구체적이고 수치상으로 어떻게 되는지 알 필요가 있고
3. DNS
   1. 호스트 네임 입력 했을 때 그것을 ip 주소로 바꿔주는, 바꿔준다기보다 ip주소에 매핑된 정보를 들고있는 시스템이었어요. 근데 이거 하나만 있으면 전세계 인터넷이 마비되기 때문에 여러곳에 있어요. 실제적인 모습은 이런형태라고 이야기를 했어요. top level dns server
   2. 현실적으로 매번 왔다 갔다하기 귀찮고 힘드니까 보통 로컬 네트웤 내부에 로컬 네임 서버를 두고 걔가 대리인으로 해서 서버 이름을 찾곤 했어요. 거기없어도 아키텍쳐 외부로 나가서 찾아오는
   3. 내가 답은 모르지만 답을 알고 있는애를 알고 있거든 걔한테가, 인다이렉트하게 가게하는 역할을 하고, 최종적으로 답은 authorative name server가 알고 있다.
4. 전송 계층
   1. UDP
      1. reliable 안하고 flow control 안 하고, congestion control안해
      2. 그럼에도 불구하고 최소한의 기능을 하는게 있었어.
      3. 헤더에 뭐가 있는지 보면 알 수 있어.
         1. length
         2. checksum
         3. source port #
         4. dest port #
      4. dns가 udp 사용하는 이유 사용량 너무많은데 이름하나 알려줄라고 3way handshake로 연결 맺고 시작하는거 너무오래걸려서.
   2. TCP,
      1. flow control
         1. 네가지 메커니즘 필요
            1. 에러디텍션
            2. 피드백
            3. 피드백에 반응하는 리트랜스미션
            4. 타이머
         2. 기본적으로 탑재하고 있어야 된다.
            1. 데이터 하나보내고 확인하는 이런 아주 간단한 거였는데, 실제로 tcp같은 경우에는 이렇게 파이프라인 방식으로 패킷 쏟아붓고, ack여러개 밤고
         3. 센드 버퍼 리시브 버퍼
         4. tcp 헤더 구조
            1. 포트넘버 - 멀티플렉싱
            2. ack # - sender 내가 몇번까지 받았는지 (리시버 역할)
            3. seq # -receiver 내가 몇번까지 보냈는지
            4. 1비트짜리 자잘한 플래그들 S === 0 보통은 0, 인데 1로 되는 순간 connection requestt되, F는 Fin 커넥션 끊을 때
            5. 얘기하지 않은 U 나 R은 넘어가자구요.
            6. 시퀀스넘버는 보내려는 데이터의 가장 앞 바이트의 번호를 넣어요.Tcp에서의 ack넘버는 cumulative ack의 의미로 지금까지 잘 받은 번호 그 바로 다음번호를 보내주게 되어요. 이예기예요. cumulative ack에 대한 예시인데, 예를 들면 중간에 ㅇㅋ가 중간에 유실됐던 것들 상쇄가 된다.
      2. cumulative ACK scenario
         1. fast retransmit
            1. timer 가 expired 되기 전에도 3번의 중복된 sequence # 가 담긴 ack retransmission을 한다

원래 리시버는 받은 세그먼트에 대한 모든 애크를 보내는데, 바로 보내지 말고 조금 기다렸다가 보내라 이게 딜레이드 ack였잖아요. 이거에 대한 애크없고 마지막거에대한 애크 하나만 나가겠죠? 그럼 한꺼번에 윈도우 사이즈가 6개가 이동이 되면서 뒤에 데이터가 계속있다고 치면, 그 뒤의 데이터 6개 (윈도우사이즈가 6개 이동했으니까) 가 뉴 트랜스미션이 생기겠죠.

결국 애크를 받았을 때 어떻게 윈도우사이즈가 행동을 하는지만 생각하면돼

애크로 받은 시퀀스 넘버를 기준으로 잘 받은거 뒤로 윈도우 사이즈를 옮겨, 그리고 가장 앞에있는 데이터에 타이머를 물려, 뒤에 생긴 새로운 뉴트랜스미션을 전송해. 이런 일련의 동작이 이루어진다.

congestion control

양끝단의 컴퓨터가 서로의 피드백을 기준으로 네트워크 상태를 짐작한다

slow start 를 한다. 한 번이라도 막힌다면 심각한 문제기 때문에 보수적으로 시작함.

타호, 르노 방식이 있음

타호 (버전 원) → 듀플리케이트 에크, 타임아웃 둘다 같은 방식으로 대응함 처음 부터 다시시작

르노 (버전 투) → 듀플리케이트 에크의 경우는 절반으로 줄여서 다시 시작하고, 타임아웃의 경우는 훨씬 심각한 경우기 때문에 (특수한 경우의 하나만 유실된게 아니라 그 많은걸 다 보내고 나서도 한개도 답이 안왔다는 뜻이기 때문) 처음부터 다시 시작한다

(처음부터 다시 시작한다느 ㄴ의미는 보내는 데이터의 크기를 아주 작게 시작해서 exponenetial로 점진적으로 늘리는 방식인데 늘리다가 한 번 막히면 초기값인 아주 작은 값부터 다시 값을 키워나가기 시작한다는 의미)