lifelog and tech

• 환경
  • Mac with Public Secured Wifi -> Public EC2 -> Private Load Balancers and Private EC2 Proxy -> docker on Private EC2

# Modify /private/etc/hosts file

127.0.0.1 <Target Domain>

# Modify .zshrc file

alias <alias name>='ssh -i <your key file name>.pem <username>@<public EC2 IP> -p <public EC2 port> \
	-g -L <local port which is not in use>:<target domain name>:<target port> \
    -g -L <local port which is not in use>:<target domain name>:<target port>'

source .zshrc
<type alias name>

터미널에서 Public EC2 에 들어가지면 브라우저에서 <접속할 타겟 도메인>:<지정한 로컬포트> 로 입력합니다.

Public EC2 를 거쳐 내부 Private 도메인에 접속이 됩니다.

이때 접속할 소스가 Public EC2 보안그룹에 허용되어 있어야 합니다.

적응형 비트전송률 스트리밍 (ABR) 은 HTTP로 스트리밍하는 것을 향상시키는 방법이다.

동영상을 인코딩하고 길이가 몇 초 인 더 작은 파일로 분할하여 세그먼트로 전송되도록 하고 (분할 프로세스)

엔드 유저의 연결이 버퍼링없이 스트리밍할정도로 빠르게 해당 영상을 다운로드 할 수 없으면 유저의 비디오 플레이어가 세그먼트 완료 후 더 작은 파일로 전환한다. (조정 프로세스)

처음 시작시에는 비디오 플레이어가 가능한 작은 비트 전송률 파일을 요청해서 시작하고 더 높은 비트 전송률 파일이 처리 가능해지면 클라이언트가 처리가능한 선에서 가장 높은 비트전송률 파일을 선택하고, 이상적으로 선정되면 해당 비트 전송률로 계속 세그먼트를 요청한다.

해당 방법으로 비디오 재생 품질이 향상될 수 있는 이점이 있다. (비디오 품질 수준 다이나믹하게 변경)

ABR을 지원하는 프로토콜은 HLS, DASH, HDS 가 있다.

• HLS (HTTP Live Streaming): HLS는 주문형 및 라이브 스트리밍 용으로 작동하며H.264 또는 H.265 인코딩 형식이 필요하다 . 일부 프로토콜과 달리 HLS는 특수 서버를 사용할 필요가 없다. 원래 HLS는 Apple 장치와만 호환되었지만 이제는 장치에 구애받지 않고있다. 그러나 Apple 장치는 HLS 형식만 허용한다.
• DASH (Dynamic Adaptive Streaming over HTTP): DASH는 특정 인코딩 표준을 요구하지 않는다.(HLS는 특정 인코딩 형식이 필요한 반면 DASH는 대부분의 인코딩 표준 사용 다 가능. MPEG-DASH는 국제 표준) 또한 모든 원본 서버는 HTTP를 통해 실행되기 때문에 DASH 스트림을 제공하도록 설정할 수 있다.(항상 서버의 방화벽에서 오픈하는 80, 443 같은 포트 이용되서 차단 위험이 낮아짐) HLS 이외의 다른 모든 형식과 마찬가지로 DASH 형식은 Apple 장치에서 작동하지 않는다. 즉 HLS는 애플 장치에서 지원해서 이용가능하지만 MPEG-DASH는 아니어서 해당 방식으로 전송되는 비디오를 애플제품은 재생할 수 없다.
• HDS (HTTP Dynamic Streaming): 원래 Adobe Flash(단종됨)와 함께 작동하도록 설계된 이 형식은 주문형 또는 라이브 스트리밍에 사용할 수 있으며 HTTP 연결을 통해 작동한다. HDS 형식은 비디오를 MP4에서 F4F(조각화된 MP4)로 변환 해야 하며 H.264 인코딩 표준. Apple 장치는 HDS 프로토콜과 호환되지 않는 유일한 장치다.

HLS와 DASH는 모두 HTTP를 통해 실행되고 전송 프로토콜로 TCP를 쓰고 세그먼트로 비디오를 구분하며 ABR을 제공하는 유사점이 있으나 위 특징으로인해 차이점이 존재한다.

AWS Cloudfront는 현재 HLS와 MPEG-DASH를 지원하고 있다.

HLS를 통해 사용자의 bandwidth에 따라 다이나믹하게 비디오 품질을 향상시킬 수 있고

MPEG-DASH를 통해 실시간으로 고퀄리티의 비디오 스트리밍을 서비스 할 수 있다.

여기에 SSL 인증서, 람다엣지 등을 결합하여 커스터마이징하여 사용할 수 있다.

ABR with AWS Cloudfront: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ABRStreaming.html

Using Cloudfront for Video Streaming: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/TypesOfStreaming.html

Creating a basic ABR streaming distribution: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-rtmp-creating-basic.html

First of all - TCP provides reliable end to end data transfer. 

It can easily enhanced at the application layer with SSL to provide security services,

and guaranteeing that all data will eventually get to it's destination.

electronic mail(SMTP), remote terminal access(Telnet), web(HTTP), and File transfer(FTP) applications are using TCP most likely.

Streaming multimedia (HTTP, RTP-real time transfer protocol) applications are using TCP or UDP,

Internet telephone - loss tolerant - application  typically is using UDP.

In earnest, congestion control and flow control are two important mechanisms in TCP (Transmission Control Protocol) that help regulate the flow of data between two endpoints in a network. Here's a brief description of each:

1. Congestion control: This mechanism is used to prevent network congestion by slowing down the rate at which data is transmitted when the network is congested. It is based on the idea of monitoring the network for signs of congestion and then adjusting the transmission rate accordingly. TCP implements congestion control by using a combination of techniques, including slow start, congestion avoidance, and congestion recovery.

• Slow start: In the beginning of a transmission, TCP starts by sending a small number of packets and then gradually increases the transmission rate until it detects signs of congestion.
• Congestion avoidance: Once congestion is detected, TCP reduces the transmission rate to avoid further congestion.
• Congestion recovery: If packets are lost or dropped due to congestion, TCP uses a mechanism called fast retransmit/fast recovery to quickly recover from the loss and resume normal transmission.

1. Flow control: This mechanism is used to prevent the receiver from being overwhelmed by too much data. It is based on the idea of regulating the flow of data from the sender to the receiver. TCP implements flow control by using a sliding window protocol.

• Sliding window protocol: The receiver informs the sender about how much data it can receive by sending a window size value. The sender then sends data up to that window size and waits for an acknowledgement from the receiver before sending more data.

By implementing both congestion control and flow control, TCP ensures that data is transmitted efficiently and reliably between two endpoints in a network.

혼잡 제어 및 흐름 제어는 네트워크의 두 끝점 사이의 데이터 흐름을 조절하는 데 도움이 되는 TCP(전송 제어 프로토콜)의 두 가지 중요한 메커니즘입니다. 각각에 대한 간략한 설명은 다음과 같습니다.

혼잡 제어: 이 메커니즘은 네트워크가 혼잡할 때 데이터 전송 속도를 늦춤으로써 네트워크 혼잡을 방지하는 데 사용됩니다. 정체의 징후에 대해 네트워크를 모니터링한 다음 그에 따라 전송 속도를 조정한다는 아이디어를 기반으로 합니다. TCP는 느린 시작, 혼잡 회피, 혼잡 복구 등의 기술 조합을 사용하여 혼잡 제어를 구현합니다.
느린 시작: 전송이 시작될 때 TCP는 적은 수의 패킷을 보내는 것으로 시작한 다음 혼잡의 징후를 감지할 때까지 점차적으로 전송 속도를 높입니다.
혼잡 회피: 혼잡이 감지되면 TCP는 추가 혼잡을 피하기 위해 전송 속도를 줄입니다.
혼잡 복구: 혼잡으로 인해 패킷이 손실되거나 누락된 경우 TCP는 빠른 재전송/빠른 복구라는 메커니즘을 사용하여 손실을 신속하게 복구하고 정상적인 전송을 재개합니다.
흐름 제어: 이 메커니즘은 수신자가 너무 많은 데이터에 압도당하는 것을 방지하는 데 사용됩니다. 발신자에서 수신자로의 데이터 흐름을 규제한다는 아이디어를 기반으로 합니다. TCP는 슬라이딩 윈도우 프로토콜을 사용하여 흐름 제어를 구현합니다.
슬라이딩 윈도우 프로토콜: 수신자는 윈도우 크기 값을 전송하여 수신할 수 있는 데이터의 양을 발신자에게 알려줍니다. 그런 다음 보낸 사람은 해당 창 크기까지 데이터를 보내고 더 많은 데이터를 보내기 전에 받는 사람의 승인을 기다립니다.
혼잡 제어와 흐름 제어를 모두 구현함으로써 TCP는 데이터가 네트워크의 두 끝점 간에 효율적이고 안정적으로 전송되도록 합니다.

UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) are two widely used protocols in computer networking. While both protocols are used to send data over a network, there are some key differences between them. Here are the main differences between UDP and TCP:

1. Connection-oriented vs Connectionless: TCP is a connection-oriented protocol, meaning it establishes a connection between the two endpoints before sending data. UDP, on the other hand, is connectionless, meaning data is sent without any prior communication or connection setup.
2. Reliability: TCP is designed to be reliable and ensures that all data is delivered to the destination in the correct order. It uses error detection and correction mechanisms to ensure that data is not lost or corrupted during transmission. UDP, on the other hand, does not have these mechanisms, and some data packets may be lost or arrive out of order.
3. Speed: UDP is generally faster than TCP because it does not have to establish a connection or perform error detection and correction. This makes it a good choice for applications that require fast data transmission, such as online gaming or video streaming.
4. Data size: TCP is better suited for larger data transmissions, as it can handle larger amounts of data without loss or corruption. UDP, on the other hand, is better suited for smaller data transmissions, such as sending sensor data or real-time voice communication.

In summary, TCP is a reliable, connection-oriented protocol that is better suited for larger data transmissions, while UDP is a faster, connectionless protocol that is better suited for smaller data transmissions that require low latency.

UDP(사용자 데이터그램 프로토콜) 및 TCP(전송 제어 프로토콜)는 컴퓨터 네트워킹에서 널리 사용되는 두 가지 프로토콜입니다. 두 프로토콜 모두 네트워크를 통해 데이터를 전송하는 데 사용되지만 두 프로토콜 사이에는 몇 가지 중요한 차이점이 있습니다. UDP와 TCP의 주요 차이점은 다음과 같습니다.

연결 지향(connection oriented) vs 비연결(connectionless): TCP는 연결 지향 프로토콜입니다. 즉, 데이터를 보내기 전에 두 엔드포인트 간에 연결을 설정합니다. 반면 UDP는 연결이 없습니다. 즉, 사전 통신이나 연결 설정 없이 데이터가 전송됩니다.

신뢰성(reliable): TCP는 신뢰할 수 있도록 설계되었으며 모든 데이터가 올바른 순서로 대상에 전달되도록 합니다. 오류 감지 및 수정 메커니즘을 사용하여 전송 중에 데이터가 손실되거나 손상되지 않도록 합니다. 반면 UDP에는 이러한 메커니즘이 없으며 일부 데이터 패킷이 손실되거나 순서 없이 도착할 수 있습니다.

속도: UDP는 연결을 설정하거나 오류 감지 및 수정을 수행할 필요가 없기 때문에 일반적으로 TCP보다 빠릅니다. 따라서 온라인 게임이나 비디오 스트리밍과 같이 (real-time applications can often tolerate loss) 빠른 데이터 전송이 필요한 애플리케이션에 적합합니다.

(그러나 많은 방화벽이 UDP를 막아서 웹디자이너들이 멀티미디어나 실시간 어플리케이션을 TCP로 전송하도록 고안하기도 합니다.)

데이터 크기: TCP는 손실이나 손상 없이 더 많은 양의 데이터를 처리할 수 있으므로 더 큰 데이터 전송에 더 적합합니다. 반면에 UDP는 센서 데이터 전송 또는 실시간 음성 통신과 같은 소규모 데이터 전송에 더 적합합니다.

요약하면 TCP는 더 큰 데이터 전송에 더 적합한 신뢰할 수 있고 연결 지향적인 프로토콜인 반면, UDP는 짧은 대기 시간이 필요한 더 작은 데이터 전송에 더 적합한 더 빠르고 비연결적인 프로토콜입니다.

A checksum is a value calculated from a set of data that is used to detect errors that may have occurred during data transmission or storage.

It is typically a simple algorithm that calculates a unique value from the data, which can then be compared to the checksum generated by the receiver to determine whether the data has been corrupted or altered.

A parity bit is a type of checksum used to detect errors in data transmission or storage. It is a single bit of data that is added to a group of bits to make the total number of 1s in the group either even or odd. The parity bit is then used by the receiver to determine whether the data has been transmitted correctly or not.

The key difference between checksum and parity bit is that checksum involves calculating a unique value from a set of data, while parity bit involves adding a single bit of data to a group of bits to make the total number of 1s either even or odd. Checksums can be more complex and can detect a wider range of errors than parity bits, but they are also more computationally intensive. Parity bits, on the other hand, are simpler and require less computational power, but they can only detect certain types of errors.

체크섬은 데이터 전송 또는 저장 중에 발생할 수 있는 오류를 감지하는 데 사용되는 데이터 세트에서 계산된 값입니다.

일반적으로 데이터에서 고유한 값을 계산하는 간단한 알고리즘으로, 수신자가 생성한 체크섬과 비교하여 데이터가 손상되었거나 변경되었는지 확인할 수 있습니다.



패리티 비트는 데이터 전송 또는 저장 오류를 감지하는 데 사용되는 일종의 체크섬입니다.(checksum type) 그룹의 총 1 수를 짝수 또는 홀수로 만들기 위해 비트 그룹에 추가되는 단일 비트의 데이터입니다. 그런 다음 패리티 비트는 데이터가 올바르게 전송되었는지 여부를 결정하기 위해 수신기에서 사용됩니다.



체크섬과 패리티 비트의 주요 차이점은 체크섬은 데이터 세트에서 고유한 값을 계산하는 반면 패리티 비트는 비트 그룹에 데이터의 단일 비트를 추가하여 1의 총 수를 짝수 또는 홀수로 만드는 것입니다. 체크섬은 더 복잡할 수 있고 패리티 비트보다 더 넓은 범위의 오류를 감지할 수 있지만 계산 집약적이기도 합니다. 반면에 패리티 비트는 더 간단하고 계산 능력이 덜 필요하지만 특정 유형의 오류만 감지할 수 있습니다.

먼저 각 레이어에 대해 기억하자.

1. Application Layer

프로토콜: HTTP, FTP, SMTP..

데이터 유닛: message

2. Presentation Layer

프로토콜: SSL/TLS, MIME (Multipurpose Internet Mail Exensions)..

3. Session Layer

프로토콜: NetBIOS (Network Basic Input/Output System), NFS (Network File System),..

4. Transport Layer

프로토콜: TCP, UDP..

데이터 유닛: segment

5. Network Layer

프로토콜: IP, ICMP..

데이터 유닛: datagram

6. Data Link Layer

프로토콜: ARP(Address Resolution Protocol), PPP (Point-to-Point Protocol)..

데이터 유닛: frame

6. Physical Layer

프로토콜: Ethernet, Token Ring, FDDI...