Posts

1.4 패킷 교환 네트워크에서의 지연, 손실과 처리율 네트워크는 반드시 두 end system 간에 처리율(전달될 수 있는 초당 뎅디터의 양)을 제한하여 end system 간에 지연을 야기하며 실제로 패킷을 잃어버리기도 한다. 1.4.1 패킷 교환 네트워크에서의 지연 개요 패킷은 한 호스트에서 일련의 라우터를 통과하며 다른 호스트까지 도달함. 경로를 따라 한 노드(호스트 혹은 라우터)에서 다음 노드로 전달될 때 다양한 지연을 겪음. nodal processiong delay(노드 처리 지연) queuing delay(큐잉 지연) transmission delay(전송 지연) propagation delay(전파 지연) 이 모두를 합쳐 total nodal delay 지연 유형 라우터 A에서 B로 보내질 때 패킷이 앞선 노드에서 도착하면 라우터 A는 패킷 헤더를 조사해서 적당한 출력 링크를 결정하고(processing delay) 만약 선택된 링크가 이용되고 있더나 큐에서 대기하는 패킷이 있다면 큐로 들어간다(queuing delay). 링크를 이용할 수 있으면 패킷을 보낸다. 패킷의 길이가 L비트, 링크의 전송률이 R bps면 transmission delay는 L/R이다(transmission delay). 비트가 링크에 전해지면 목적지인 라우터 B까지 전달되야 한다. 이 전파 속도는 링크의 물리 매체에 따라 다르다(propagation delay). 전송 지연과 전파 지연 비교 전송지연 전송률과 패킷 길이 라우터가 패킷을 내보는데 필요한 시간 한 개의 패킷 내에서 첫번째 비트부터 마지막 비트까지 라우터를 빠져나오는데 걸리는 시간. 이전에 말했듯, 첫번째 비트는 마지막 비트가 도착할때까지 저장되어있어야 함. 마지막비트가 라우터에 도착하고나서야 첫번째 비트는 다음 목적지로 전송된다. 전파지연 비트가 한 라우터에서 다음 라우터로 전파되는데 걸리는 시간 링크의 물리적 길이 라우터를 빠져나와 다음 라우터까지 도달하는데 걸리는 시간. 패킷이 라우터에 저장되는 시간으로부터 다음 라우터에 저장될때 까지의 시간은 전송지연과 전파지연의 합. 당연히 마지막 비트가 전송되기도 전에 앞선 비트가 다음 라우터에 도착할 수도있다. 1.4.2 큐잉 지연과 패킷 손실 다른 지연들과 달리 큐잉 지연은 패킷마다 다를 수 있다. 여러 패킷이 동시에 비어있는 큐에 도착한다면, 처음 큐에 들어간 패킷과 마지막에 들어간 패킷의 큐잉 지연은 크게 차이난다. 따라서 큐잉 지연은 통계 측정을 일반적으로 사용한다. 큐잉 지연은 트래픽이 큐에 도착하는 비율, 링크의 전송률 ,도착하는 트래픽의 특성에 따라 달라진다. 예시 패킷이 큐에 도착하는 평균율 : a 패킷/초 전송률(비트가 큐에서 밀려나는 비율) : R 비트/초 모든 패킷 : L 비트 따라서 평균율의 단위를 비트로 바꾸면 La 비트/초 이다. 트래픽 강도(traffic intensity) : La/R (트래픽 강도) > 1 인 경우 비트가 큐에 도착하는 평균율이ㅐ 비트가 큐에서 전송되는 비율을 초과한다. La/R > 1이면, La > R이므로 큐에 도착하는 비트의 수가 다음 목적지로 전송되는 비트보다 많다. 큐에서 처리되는 비트보다 쌓이는 비트가 많아지므로, 점차 큐잉 지연은 커질것이다. 따라서 트래픽 공학에선, 트래픽 강도가 1보다 크지 않게 시스템을 설계하라는 규칙이 있다. (트래픽 강도) ≤ 1인 경우 패킷이 주기적으로 도착한다면, 쌓이는 것보다 처리되는 것이 빠르기 떄문에 큐잉 지연이 없을 것이다. 하지만 패킷이 몰려서(버스트) 도착한다면 큐잉 지연은 존재할 것이다. 이게 반복되면 몰려서 도착하는 패킷의 횟수만큼 점차 큐잉 지연이 늘어날 것이고, 이에 따라 평균 큐잉 지연을 계산할 수 있다. 실제로, 큐에 도착하는 프로세스는 랜덤하다.\ 또한 이 예시에선 큐가 무한한 패킷을 담을 수 있다고 가정했다. 하지만 트래픽 강도가 1에 가까울 수록, 큐잉 지연이 기하급수적으로 늘어나는 건 알아둬야 함. 패킷 손실 실제로 큐는 무한한 패킷을 담을 수 없다. 따라서 큐잉지연이 무한하게 증가하지 않는다. 패킷이 도착했을 때 큐가 꽉 차있다면, 패킷은 버려지고(drop), 잃어버리게(lost) 된다. 트래픽 강도가 높을 수록, 손실 패킷의 비율은 증가한다. end system에 입장에선, 패킷이 네트워크 코어로 전송되었으나 목적지에 나타나지 않는 것 처럼 보인다. 1.4.3 종단 간 지연 위 과정들은, 단일 라우터에서를 초점으로 두었다. 출발 호스트와 목적 호스트 사이에 N-1개의 라우터(즉, N개의 링크)가 있다고 가정. d(proc) = 각 라우터와 출발지 호스트의 처리 지연 R 비트/초 = 각 호스트와 출발지 호스트에서의 전송률 d(prop) = 각 링크에서의 전파 지연 L = 패킷 크기 d(trans) = L/R (전송지연) d(end-end) = 종단 간 지연 = N * (d(proc) + d(trans) + d(prop)) Traceroute 컴퓨터 네트워크에서의 지연을 느낄 수 있는 진단 프로그램’ 종단 시스템, 애플리케이션 그리고 그 밖의 지연 이외에도 다른 중요한 지연들 도 있다. 종단 시스템에서 매체를 공유하기 위해 프로토콜의 일부로 전송을 의도적으로 지연 시킬 수도 있다. media packetization delay(미디어 패킷화 지연)은 VoIP(Voice-over-IP)에서 송신 측은 먼저 패킷을 인터넷으로 보내기 전에 패킷을 인코딩된 디지털 음성으로 채워야 한다. 1.4.4 컴퓨터 네트워크에서의 처리율 지연과 패킷 손실 외에 컴퓨터 네트워크에서 성능과 연관된 요소는 throughput(처리율) 이다. instantaneous throughput(순간적인 처리율), average throughput(평균 처리율) 예시 서버 → 라우터 → 클라이언트로 연결되어있다고 가정해보자. 서버와 라우터간의 링크 속도는 R(s)고, 라우터와 클라이언트의 링크 속도는 R(c)이다. 서버는 라우터로 R(s)의 속도로 비트를 보내고, 라우터는 클라이언트로 R(c)의 속도로 전송한다. R(s) < R(c) 일때, 결국 클라이언트는 서버로부터 R(s)의 처리율로 비트를 받는다. R(s) > R(c) 일때, 서버가 라우터로 아무리 빨리 보내더라도 결국 클라이언트는 R(c)의 속도로 비트가 처리되는 것처럼 느낀다. 따라서 이 네트워크의 처리율은 min{R(c), R(s)} 가 된다. **bottleneck link(병목 링크)**의 전송률이 처리율이 된 상황이다. 이처럼 일직선으로 되어있는 네트워크에서 서버가 클라이언트로 파일을 전송하는 경우의 처리율은 링크 속도 중 최솟값이고, 이는 병목 링크의 전송률이다. 10개의 서버와 10개의 클라이언트가 있다고 가정해보자. 서버와 클라이언트간의 연결은 모두 단 하나의 코어 링크를 지난다고 생각해보자. 어떤 서버가 어떤 클라이언트에게 파일을 전송하든, 코어 링크를 지나야 한다. R(s) : 서버와 코어링크 사이의 링크 속도 R(c): 클라잉너트와 코어 링크 사이의 링크 속도 R : 코어 링크의 링크 속도 만약 R이 R(s)와 R(c)보다 월등히 크다면, 코어 링크가 끼치는 영향은 무의미하다. 따라서 병목은 R(s)와 R(c) 중 최솟값이 된다. 하지만 R이 R(s), R(c)와 비슷하다면? R(s) = 1 Mbps, R(c) = 2 Mbps고 R = 5 Mbps 라면 어떨까? 공통된 코어 링크는 10개의 서버-클라이언트 쌍에게 전송률을 나눈다. 하나의 통신은 500 Kbps를 가지게 된다. 그렇다면 병목은 R(s)나 R(c)가 아니라 공통된 코어링크가 된다.

Today I Learned 날짜 2024년 1월 15일 월요일 내용 드으으으으디어 ECS를 해결했다! ECS 정복 직전 너무 자주 말한듯 하지만.. ECS 클러스터가 S3 버킷에서 환경변수를 가져오지 못하고 있었다. 질문 I am encountering an issue with my ECS service where tasks are consistently failing during deployment. The specific error message I receive is as follows: 1 ResourceInitializationError: failed to download env files: file download command: non empty error stream: service call has been retried 5 time(s): RequestCanceled: request context canceled caused by: context deadline exceeded ECS tasks are configured to download environment files from an S3 bucket. My ECS service is in the Seoul region (ap-northeast-2), and the S3 bucket is in the US East (Ohio) region (us-east-2). The S3 bucket and objects are not set to public access. I suspect that the issue might be related to timeout settings, as the error indicates that the request is canceled after multiple retries due to a context deadline being exceeded. I have tried setting the startTimeout and stopTimeout in the task definition JSON to 120 seconds, but this has not resolved the issue. ...

2024년 1월 15일 알고리즘 문제풀이 문제 피보나치 수 난이도 Lv. 2 코드 1 2 3 4 5 6 7 8 def solution(n): dp = [0 for _ in range(n+1)] dp[1] = 1 if n<2: return dp[n] for i in range(2,n+1): dp[i] = (dp[i-1]+dp[i-2])%1234567 return dp[n]

1.3 네트워크 코어 1.3.1 패킷 교환 end system : message 교환 packet: message의 분할 packet은 통신 링크와 packet switch를 거침 저장-후-전달 store-and-forward transmission : switch가 한 패킷 내의 모든 비트를 받아야만 전송 시작 초당 R비트의 속도로 총 L 비트을 전송하는건 L/R초 소모. 이 방식으로, L비트 짜리 패킷 1개가 엔드시스템 → 라우터 → 엔드시스템 으로 갈떄 걸리는 시간은 2L/R 받고 저장하는데 L/R + 다시 보내는데 L/R 전체 이 방식이 아니라 받는 비트별로 보내면 L/R 일 것. L 비트짜리 패킷이 3개라면? L/R 초 후 : 출발지가 송신, 라우터가 수신 2L/R 초 후 출발지가 2번째 패킷 송신, 라우터가 첫번째 패킷 송신과 두번째 패킷 수신, 목적지가 첫번째 패킷 수신 결국 4L/R 걸린다. 일반화해서, 출발지부터 목적지까지 N개의 링크로 구성(N-1개의 라우터가 존재한다는 의미)되어있고 전송률이 R이라면 종간 간 지연은 NL/R 큐잉 지연과 패킷 손실 각 패킷 스위치는 여러개의 링크를 가질 수 있음 각 링크에 대해 output buffer(output queue)를 가짐. 송신받은 패킷을 보낼려는 링크가 다른 패킷을 전송하고 있다면 output buffer에서 대기 : queuing delay output buffer 조차도 꽉차있다 : packet loss 흔한 일 : 출발지 → 라우터 는 100Mbps지만 라우터 → 목적지가 15Mbps라면 기다려야함 포워딩 테이블과 라우팅 프로토콜 보내야 할 링크를 아는 방법: IP 주소(계층적 구조 like 우편주소) forwarding table 패킷이 라우터에 도착하면 올바른 출력링크를 찾기 위해 주소의 일부를 조사 주소를 이용해 forwarding table 검색 그 패킷을 출력링크로 보냄 인터넷은 자동으로 forwarding table을 설정하는데 이용하는 routing protocol을 갖고 있음. 1.3.2 회선교환 데이터를 이동시키는 방식 : circuit switching, packet switching(지금까지 본것) circuit swtiching(회선 교환) 통신 session 동안 resource들을 reserve. 전화망 : circuit(회선)이 송수신자간의 연결 상태를 유지해서 guaranteed된 전송률 보장 각 링크가 여러개의 회선을 가져 이 중 하나를 reserve 할 수 있음 (전송용량의 1/n) 회선 교환 네트워크에서의 다중화 FDM(frequency-division multiplexing, 주파수 분할 다중화), TDM(time-division multiplexing, 시분할 다중화) : 회선을 동시에 공유할 것인가? 시간마다 번갈아가면서 전체를 쓸것인가? FDM 링크를 통해 설정된 연결은 링크의 주파수 스펙트럼을 공유. 대역폭(bandwidth): 링크가 연결되는 동안 각 연결에 대해 고정제공하는 주파수 대역의 폭 FM 라디오는 88Mhz~108MHz 사이를 공유(방송국마다 할당) TDM 시간을 일정 주기의 프레임으로 구분, 각 프레임은 고정된 수의 시간 슬롯으로 나눔 단점 : silent period(비활용기간) ⇒ 통화할때 이야기를 주고받지 않아도 다른 네트워크자원으로 쓸 수 없이 연결되어있음 : 낭비? A 에서 B로 n비트를 보낼떄, 모든 링크가 k개의 슬롯을 가지고 전송률이 v인 TDM 이라면? 각 회선의 전송률은 v/k (v만큼을 k개가 나눠쓰니까) 전송시간은 n/(v/k)초 가된다. 패킷 교환 대 회선 교환 패킷교환의 장점 패킷 교환이 회선 교환 전송 용량의 공유에서 더 효율적이다. 패킷 교환이 더 간단하고 효율적이며 회선 교환보다 더 구현 비용이 적다. 패킷교환의 단점 가변적이고 예측할 수 없는 종단 간의 지연(주로 불규칙적이고 예측할 수 없는 큐잉 지연에서 발생) 때문에 패킷 교환이 실시간 서비스(ex. 전화 통화)에는 적당하지 않음. 패킷교환이 효율적인 이유 패킷교환은 요구할떄만 링크의 사용을 할당하기 때문이다. 1.3.3 네트워크의 네트워크 종단 시스템은 접속 ISP를 통해 인터넷에 연결된다. 하지만 이는 인터넷 망에서 극히 일부에 불과하다. 접속 ISP들이 연결되어야 하기 떄문에, 네트워크의 네트워크 개념이 탄생했다. ISP들이 전 세계에 있는 모든 ISP들과 연결하는 것은 비용적으로 비효율적이다.(네트워크 구조 1) 가장 상위에 단 1개에 글로벌 ISP도 존재하기 힘들다. 이 지위를 얻기 위해 경쟁할 것이고, 두 경쟁은 서로 연결하지 않을 것이기 때문에, 다른 글로벌 ISP를 이용하는 end system간 통신은 불가능해진다.(네트워크 구조 2) 12개 정도의 1계층 ISP - 국가 ISP - 지방 ISP 순으로 연결(네트워크 구조 3) 여기에 Pop, 멀티홈, 피어링, IXP가 추가되어야 한다(네트워크 구조 4) 콘텐츠 제공자 네트워크도 추가된다.(네트워크 구조 5)

Today I Learned 날짜 2024년 1월 12일 금요일 내용 타운홀미팅이 있어 오전밖에 시간이 없었다. 딱히 시간이 있었다고 해결이 됐을 것 같진 않지만.. SEO HTML의 <meta> 태그는 해당 페이지에 대한 다양한 정보를 표현하기 위해 사용한다. 쉬운 부분이라 다들 알겠지만, 나는 속성에 대해 몰랐던 부분이 있었는데, title 속성은 없다. meta가 아니라 head에 title 태그를 추가하면 된다. 최근 keyword 속성은 잘 쓰지 않는다. 너도 나도 이것 저것 추가를 많이 하다보니 알고리즘이 신경쓰지 않는다고 한다. description : 뭔가 읽기 편하고, 간결한게 좋을 것 같지만 사실 최근에는 검색의 핵심이다. 타겟 유저가 검색에 포함할 법한 단어가 포함되어 있는 것이 좋다. 따라서 동어반복은 좋지 않다. 그렇다고, 말이 안되는 단순 단어 나열만 작성하면 알고리즘이 무시한다. 이정도…? 구글 검색 봇의 마음은 참 갈대같다. ...

2024년 1월 12일 알고리즘 문제풀이 문제 햄버거 만들기 난이도 Lv. 1 코드 배열을 순회하면서 순서대로 필요한 재료가 나오면 만들 수 있는 갯수를 하나 추가해주고, 해당 재료들을 제거해주었다. 이 방법은 틀렸는데, 재료가 연속해서 나와야 하기 떄문이다. 연속이라고 써놓지 좀… 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def solution(ingredient): answer = 0 arr = [1,2,3,1] while True: idx = 0 for x in range(len(ingredient)): if idx ==4: answer += 1 break if ingredient[x] == arr[idx]: idx += 1 ingredient[x] = 10 else: if idx == 4: answer += 1 else: return answer 그래서 하나씩 배열로 옮기면서, 최근 옮긴 4개로 햄버거를 만들 수 있다면 만들고 제거하도록 로직을 바꾸었다. ...

Today I Learn 날짜 2024년 1월 11일 목요일 내용 하루종일 코드보단 AWS 설정만 건드렸다. DMARC Shopify에서 메일이 왔다. Gmail과 Yahoo에서 DMARC에 관한 정책이 바뀌었다는 내용이다. 우리가 커스텀 도메인을 사용하기 위해, 이 정책에 맞게 DMARC를 추가해주어야 한다. 아니면, 2월부터는 Shopify 쪽에서 제공하는 계정으로 발송처리 된다. 고객들이 알파리뷰가 보낸 메일임을 알 수 있도록 커스텀 메일주소를 계속 유지시켜야 한다. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 이메일 인증 프로토콜이다. 이메일 도메인 소유자가 이메일 스푸핑으로 알려진 무단 사용에서 도메인을 보호할 수 있도록 설계되었다. DMARC의 구현 목적은 비즈니스 이메일 공격, 피싱 이메일, 이메일 사기 등 사이버 위협 행위에 도메인이 이용되지 않게 보호한다. <위키백과> ...

2024년 1월 11일 알고리즘 문제풀이 문제 자릿수 더하기 난이도 Lv. 1 코드 1 2 3 4 5 6 def solution(n): answer = 0 arr = list(str(n)) for x in arr: answer += int(x) return answer

Today I Learned 날짜 2024년 1월 10일 수요일 내용 빨리 빨리 처리를 못하니 업무가 쌓인다. 똑띠 한번에 처리하자. 리뷰 처리 오늘 또 실수를 했다. 리뷰가 작성되면, 유저는 이름, 성 , 이메일 등을 입력해야 한다. 이때 입력한 이메일로 DB에서 고객정보를 탐색해 이름과 성을 덮어쓰고 저장했다. 어제 이 부분을, 덮어쓰지 않고 저장하도록 코드를 변경했다. 확인해보니 이름이 저장되지 않고 비어있었다. 작성된 리뷰를 저장할 때 사용하는 클래스는 여러가지가 있다. 기본 클래스를 바탕으로, 스토어 리뷰와 주문한 고객의 리뷰(검증된 리뷰), 주문하지 않은 고객의 리뷰(검증되지 않은 리뷰), 관리자의 리뷰가 모두 대동소이하다. 각 클래스는 비슷한 메서드를 필요에 맞게 각각 정의하고 있다. ...

Today I Learned 날짜 2024년 1월 9일 화요일 내용 이거하랴 저거하랴 정신 없는 하루였다. 내일 별일 없겠지.. Weekly Review Report email 보완 어제 전송되었어야 할 메일들이 전송되지 않았다. 해당 Task가 등록된 service의 로그를 확인해보았는데, 두가지 오류를 발견했다 invalid HTTP request received 라는 오류가 있었는데, 내가 새로운 Task 예약 규칙을 생성하기 전부터 찍혀오던 오류였다. 따라서 내가 추가한 것과는 무관한 로그라고 판단했다. ResponseValidationError : UTC 시간 기준으로 어제 오전 10시에 한번 찍혀있는 로그였다. 이전에 비슷한 오류가 발생하지 않아 내 Task가 작동하지 않은 원인일 거라고 추정했지만 석연치 않은 부분도 있었다. 내 Task는 매주 월요일 오전 0시 부터 1시간 간격으로 24번 실행되야 한다. 따라서 코드가 잘못되어 에러가 발생했으면 오전 1시 이전에 발생했어야 맞다. 혹시 설정이 잘못되었나 싶어 이것저것 살펴보다가 내가 만든 예약 Task의 Task definition이 개정된 버전이 지정되있지 않아 잘못된 Task definition이 걸려있었다. 수정하려고 설정에 들어갔을 때는 제대로 설정되어 있는데.. 버그인가 싶어 제대로 고쳐주고 내일 다시 실행되도록 했다. 내일은 제발 되었으면.. ...