<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>steel-hyuk.log</title>
        <link>https://velog.io/</link>
        <description>back-end engineer</description>
        <lastBuildDate>Sat, 08 Apr 2023 04:52:46 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>steel-hyuk.log</title>
            <url>https://images.velog.io/images/steel-hyuk/profile/cd8e10e0-65f3-4f78-b565-0312d1bceedb/social.png</url>
            <link>https://velog.io/</link>
        </image>
        <copyright>Copyright (C) 2019. steel-hyuk.log. All rights reserved.</copyright>
        <atom:link href="https://v2.velog.io/rss/steel-hyuk" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[[TIL] DNS]]></title>
            <link>https://velog.io/@steel-hyuk/TIL-DNS</link>
            <guid>https://velog.io/@steel-hyuk/TIL-DNS</guid>
            <pubDate>Sat, 08 Apr 2023 04:52:46 GMT</pubDate>
            <description><![CDATA[<h3 id="dns-domain-name-system">DNS (Domain Name System)</h3>
<p>도메인 주소를 IP 주소로 바꿔주는 시스템</p>
<p>ex) 
사람을 식별하는 방법</p>
<ul>
<li>주민번호, 이름, 여권번호
인터넷 호스트, 라우터 식별하는 방법</li>
<li>IP주소 - datagram에 주소를 부여하기 위해 사용</li>
<li>&quot;이름&quot; (<a href="http://www.abc.com">www.abc.com</a>) - 사람이 사용</li>
</ul>
<p>IP 주소와 이름을 어떻게 매핑할 것인가 ?
=&gt; DNS</p>
<ul>
<li>분산된 데이터베이스: 여러 계층의 name server들로 구현됨</li>
<li>애플리케이션 계층 프로토콜: 호스트와 네임서버들은 주소-이름 변환을 위해 통신함</li>
</ul>
<p>DNS 서비스</p>
<ul>
<li>호스트 이름과 IP주소의 변환</li>
<li>host aliasing
ㅁ 정식이름(canonical name), 별칭(alias name)을 관리</li>
<li>mail server aliasing</li>
<li>부하 분산
ㅁ 중복된 웹 서버들: 여러 IP주소가 하나의 이름에 연관되어 있음.</li>
</ul>
<p>중앙집중식의 문제?</p>
<ul>
<li>서버의 고장이 전체를 마비시킴</li>
<li>트래픽의 양</li>
<li>중앙집중 DB까지의 거리</li>
<li>유지관리</li>
</ul>
<p>-&gt; 확장성이 없다 =&gt; 분산식의 서버를 사용</p>
<p>분산 계층 데이터베이스
<img src="https://velog.velcdn.com/images/steel_hyuk___2/post/41efc488-7cec-42e7-8764-1210ea6c446c/image.png" alt="">
클라이언트가 <a href="http://www.amazon.com%EC%9D%98">www.amazon.com의</a> IP 주소를 찾는 과정</p>
<ol>
<li>클라이언트는 root server에 질의해 com DNS server를 알아낸다</li>
<li>클라이언트는 .com DNS server에 질의해 amazon.com DNS server를 알아낸다</li>
<li>클라이언트는 amazon.com DNS server에 질의해 <a href="http://www.amazon.com%EC%9D%98">www.amazon.com의</a> IP 주소를 알아낸다.</li>
</ol>
<h4 id="root-name-server">Root name server</h4>
<ul>
<li>지역 name server가 이름을 변환하고자 할 때 접속한다</li>
<li>root name server
ㅁ 매핑 정보를 모르면 책임 서버에 접속
ㅁ 매핑 정보를 얻는다
ㅁ 지역 네임 서버에 그 정보를 돌려준다</li>
</ul>
<p>전세계에 13개의 logical root name server가 있다.</p>
<h4 id="tld-서버-책임-dns-서버">TLD 서버, 책임 DNS 서버</h4>
<p>최상위 레벨 도메인(Top-Level Domain) 서버</p>
<ul>
<li>com, org, net, edu, aero, jobs, museums 등과 최상위 국가 도메인(ex. uk, fr, ca, kr)을 책임진다</li>
<li>Network Solutions 사가 .com TLD 서버를 관리함</li>
<li>Educause 사가 .edu TLD 서버를 관리함</li>
</ul>
<p>책임 (authoritative) DNS 서버</p>
<ul>
<li>각 기관은 자신의 DNS server를 가지고, 기관 내 호스트 들의 이름-IP 매핑을 제공한다</li>
<li>기관에서 자체적으로 관리하거나, 또는 인터넷 서비스 제공자가 관리한다</li>
</ul>
<h4 id="로컬-dns-name-server">로컬 DNS name server</h4>
<ul>
<li>계층 구조에 정확히 들어맞지는 않는다</li>
<li>각 ISP에 하나씩 있다
ㅁ default name server라고도 한다</li>
<li>호스트가 DNS 질의를 하면, 로컬 DNS 서버에 보내진다.
ㅁ 캐시에 최근의 이름-주소 변환 쌍을 보관하고 있음
ㅁ 프록시 역할을 하여, 질의를 DNS 계층 구조에 전달함</li>
</ul>
<p>로컬 DNS vs 책임 DNS</p>
<pre><code>캐싱 DNS 서버라고도 하는 로컬 DNS 서버는 클라이언트가 도메인 이름을 IP 주소로 확인하는 데 사용하는 일종의 DNS 서버입니다. 
최근에 액세스한 도메인 이름 확인 정보를 캐시하여 동일한 도메인 이름에 대한 향후 요청에 신속하게 응답할 수 있습니다. 
로컬 DNS 서버는 일반적으로 인터넷 서비스 공급자(ISP) 또는 로컬 네트워크 내에서 사용됩니다.


반면 권한 있는 DNS 서버는 특정 도메인에 대한 결정적인 정보가 있는 DNS 서버입니다. 
신뢰할 수 있는 도메인 이름에 대한 쿼리에 대한 답변을 제공합니다. 
신뢰할 수 있는 DNS 서버는 특정 도메인 이름에 대한 DNS 레코드를 저장하고 유지 관리합니다.


로컬 DNS 서버와 신뢰할 수 있는 DNS 서버의 주요 차이점은 저장하는 DNS 레코드의 유형입니다. 
로컬 DNS 서버는 자주 액세스하는 레코드를 캐시에 저장하는 반면 권한 있는 DNS 서버는 권한이 있는 도메인에 대한 실제 DNS 레코드를 저장합니다. 
로컬 DNS 서버는 권한 있는 DNS 서버에 의존하여 캐시에 없는 도메인에 대한 올바른 DNS 레코드를 제공합니다.


요약하면 로컬 DNS 서버는 최근에 액세스한 도메인 이름 확인 정보를 캐시하고 도메인 이름을 IP 주소로 확인하는 프로세스를 가속화하는 데 사용됩니다. 
반면 권한 있는 DNS 서버는 특정 도메인에 대한 실제 DNS 레코드를 제공하고 정보가 최신 상태인지 확인하는 역할을 합니다.</code></pre><p>반복적 질의 (iterated query)</p>
<ul>
<li>질의를 받은 서버는 다음에 접속할 서버의 이름을 돌려준다</li>
<li>난 모르지만 이 서버에 물어보시라 ~</li>
</ul>
<p>재귀적 질의 (recursive query)</p>
<ul>
<li>질의를 받은 네임서버는 주소를 알아내서 돌려준다</li>
<li>상위 계층에 과부하 ?</li>
</ul>
<p>캐싱과 갱신</p>
<ul>
<li>네임 서버가 매핑 정보를 얻으면, 그것을 캐시에 저장한다
ㅁ 캐시의 정보는 일정시간(TTL) 후에 무효화된다.
ㅁ TLD server는 로컬 네임 서버에 캐싱된다</li>
<li>캐싱된 내용은 낡은 정보일수도,,, (best effort 방식의 이름-주소 변환)
ㅁ 만일 해당 이름의 호스트가 ip 주소를 바꾸면 TTL이 만료될 때까지 찾지 못할 수 있음</li>
<li>갱신 / 통보 매커니즘이 IETF 표준으로 제안됨 : RFC 2136</li>
</ul>
<p>DNS 레코드
DNS: 자원레코드 (resource records, RR)가 저장된 분산 DB
RR 형식 : (name, value, type, ttl)</p>
<ul>
<li>type=A
ㅁ name: 호스트 이름
ㅁ value: IP 주소</li>
<li>type=NS
ㅁ name: 도메인 (예: foo.com)
ㅁ value: 이 도메인의 책임 네임 서버의 이름</li>
<li>type=CNAME
ㅁ name: 별칭
ㅁ 예를 들어 <a href="http://www.ibm.com%EC%9D%80">www.ibm.com은</a> 사실 servereast.backup2.ibm.com
ㅁ value: 정식 이름</li>
<li>type=MX
ㅁ value: name과 연관된 메일 서버의 이름</li>
</ul>
<p>DNS protocol, messages</p>
<ul>
<li>query, reply 메시지는 같은 형식을 사용함</li>
<li>UDP 사용</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[DB Index]]></title>
            <link>https://velog.io/@steel-hyuk/DB-Index</link>
            <guid>https://velog.io/@steel-hyuk/DB-Index</guid>
            <pubDate>Sat, 04 Feb 2023 04:14:31 GMT</pubDate>
            <description><![CDATA[<h1 id="db-index">DB Index.</h1>
<p>데이터베이스의 테이블에 대한 검색 속도를 향상시켜주는 도구</p>
<p>테이블의 특정 컬럼에 인덱스를 생성하면, 해당 컬럼의 데이터를 정렬한 후 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장한다. (물리적 주소와 컬럼의 값 - key, value의 한 쌍)</p>
<p>장점: 테이블 검색 속도 및 성능 향상 ⇒ 시스템 전반적인 부하 감소</p>
<p>인덱스에 의해 데이터들은 정렬된 형태를 갖는다. Where문으로 특정 조건의 데이터를 찾기 위해서 테이블의 전체를 조건과 비교해야 하는 풀 스캔 작업과 비교해서, 인덱스는 데이터들이 정렬되어 있기 때문에 조건에 맞는 데이터를 빠르게 찾을 수 있다. </p>
<p>⇒ ORDER BY, MIN/MAX 역시도 이미 정렬되어 있기 때문에 빠르게 수행 가능</p>
<p>단점</p>
<ol>
<li>인덱스를 관리하기 위한 추가 작업 필요</li>
<li>추가 저장 공간 필요</li>
<li>잘못 사용하는 경우 외려 성능 저하</li>
</ol>
<p>인덱스를 항상 정렬된 상태로 유지해야 하기 때문에 인덱스가 적용된 컬럼에 삽입, 삭제, 수정 작업을 수행하면 추가 작업이 필요하다. (인덱스의 추가도 추가적으로 필요)</p>
<p>인덱스의 수정이 필요할 때는 기존의 인덱스를 사용하지 않는다는 작업을 수행하고 새로운 인덱스를 추가함.</p>
<p>⇒ 수정 작업이 많은 경우 실제 데이터에 비해 인덱스가 과도하게 커지는 문제점 발생 (추가 저장 공간 많이 필요)</p>
<p>전체 데이터의 10~15% 이상의 데이터를 처리하거나, 데이터의 형식에 따라 성능 낮아질 수 있음. (나이나 성별 같이 값의 범위가 적은 컬럼의 경우, 인덱스를 읽고 나서 다시 많은 데이터를 조회해야 하기 때문에 비효율적이다.)</p>
<p>인덱스를 사용하면 좋은 경우</p>
<p>데이터의 범위가 넓고 중복이 적고 조회가 많거나 정렬된 상태가 유용한 컬럼에 사용하는 것이 좋다.</p>
<p>Clustered Index : MySQL이 자동으로 설정하는 Index</p>
<ol>
<li>해당 테이블에 Auto increments 값으로 Primary Key가 있다면 해당 컬럼이 Clustered Index</li>
<li>없다면, 컬럼 중에 Unique 컬럼이 Clustered Index</li>
<li>없다면, MySQL이 내부적으로 Hidden Clustered Index Key (row ID)를 만들어 사용</li>
</ol>
<p>위 세 가지 경우의 공통점은 ?</p>
<p>Non Clustered Index : 개발자가 설정하는 모든 Index</p>
<p>멀티 컬럼 Index의 경우 최대 16개의 컬럼을 사용할 수 있고, 테이블 당 인덱스의 개수는 최대 64개까지 지정이 가능 (Clustered Index까지 65개)</p>
<p>⇒ 멀티 컬럼 인덱스는 단일 컬럼 인덱스보다 비효율적이기 때문에 사용에 신중해야 한다.</p>
<p>Index를 설정했지만 Full scan으로 동작하는 경우</p>
<ul>
<li>컬럼의 가공</li>
<li>부정형 (! =)</li>
<li>like 앞 %</li>
<li>count(*)</li>
</ul>
<p>자료구조</p>
<ol>
<li>해시 테이블 : key와 value를 한 쌍으로 데이터를 저장하는 자료구조</li>
</ol>
<p>(key, value)로 쌍을 표현하며, key값을 이용해 대응되는 value값을 구하는 방식.</p>
<p>해시 충돌이라는 변수를 제외하면 O(1)의 매우 빠른 시간만에 데이터를 탐색할 수 있다.</p>
<p>그렇지만, Index에서 해시 테이블은 사용되지 않음. why ?</p>
<ol>
<li>B- Tree : 탐색 성능을 높이기  위해 균형 있게 높이를 유지하는 Balanced Tree의 일종</li>
</ol>
<p>모든 leaf node가 같은 level로 유지되도록 밸런스를 맞춘다.</p>
<p>자식 node의 개수가 2개 이상이며, node 내의 key가 1개 이상일 수 있다.</p>
<ul>
<li>node의 key 수가 k개라면, 자식 node의 수는 k+1개</li>
<li>node의 key는 반드시 정렬된 상태</li>
<li>자식 node들의 key는 현재 node의 key를 기준으로 크기 순으로 나뉘게 됨.</li>
<li>root node는 항상 2개 이상의 자식 node를 가짐 (root node = leaf node 제외)</li>
</ul>
<p><img src="https://velog.velcdn.com/images/steel-hyuk/post/f840fb97-c9b8-4ef6-aaa3-37037285e2d7/image.png" alt=""></p>
<p>노랑 : 자식 node를 가리키는 포인터</p>
<p>숫자 담긴 네모 : key</p>
<p>숫자 : data(value)</p>
<p>B-Tree의 탐색</p>
<ul>
<li>key의 개수 / 2 + 1 번째 값을 올림</li>
</ul>
<p>B-Tree의 삽입</p>
<ul>
<li>탐색 후 해당 위치에 삽입 후 key의</li>
</ul>
<p>B-Tree의 삭제</p>
<ul>
<li>삭제할 key가 leaf node에 있는 경우<ul>
<li>현재 node의 key 수가 최소보다 큰 경우 (14)</li>
<li>현재 node의 key 수가 최소이고, 왼쪽 또는 오른쪽 형제 node의 key수가 최소보다 큰 경우 (10)<ul>
<li>삭제할 위치를 Parent로 바꿈</li>
<li>왼쪽 형제 node의 key 수가 최소보다 크다면 Lmax로, 오른쪽에서 그렇다면 Rmin으로 Parent.</li>
</ul>
</li>
<li>현재 node와 왼쪽, 오른쪽 형제 node의 key수가 최소, 부모 node의 key 수가 최소보다 큰 경우 (16)<ul>
<li>값을 삭제하고 parent를 부모 node에서 분할하여 형제 node와 병합</li>
</ul>
</li>
<li>현재 node와 왼쪽, 오른쪽 형제 node, 부모 node 모두 key 수가 최소인 경우<ul>
<li>하단 설명(현재 node와 자식 node 모두 key 수가 최소인 경우)과 동일</li>
</ul>
</li>
</ul>
</li>
<li>삭제할 key가 leaf node를 제외한 node에 있는 경우<ul>
<li>현재 node 또는 자식 node의 key수가 최소보다 큰 경우 (15)<ul>
<li>K의 Lmax또는 Rmin과 자리를 바꾸고 삭제</li>
</ul>
</li>
<li>현재 node와 자식 node 모두 key 수가 최소인 경우 (4)<ul>
<li>트리를 재구조화해야한다.</li>
<li>K를 삭제, K의 양쪽 자식을 하나로 합친다 (a)</li>
<li>K의 parent를 K의 형제 node에 병합 (b)</li>
<li>a를 b의 자식이 되도록 연결</li>
<li>b의 key 수가 최대보다 크면 key 삽입 과정과 동일하게 분할</li>
<li>b의 key 수가 최소보다 작다면 a생성 이후부터 동일 과정 반복</li>
</ul>
</li>
</ul>
</li>
</ul>
<ol>
<li>B+ Tree : 오직 leaf node에만 데이터를 저장하고 leaf node가 아닌 node에서는 자식 포인터만 저장</li>
</ol>
<p>leaf node끼리는 Linked list로 연결되어있다. </p>
<p>B- Tree는 어느 한 데이터 탐색은 효율적이지만, 모든 데이터 순회에는 모든 노드를 방문해야하므로 단점을 개선</p>
<p>leaf node를 제외하고 데이터를 저장하지 않기 때문에 메모리 확보, 하나의 node에 더 많은 포인터를 가질 수 있기 때문에 트리의 높이가 낮아짐, 검색 효율</p>
<p>풀스캔의 경우 B+Tree는 leaf node에만 데이터가 저장되고 연결리스트로 연결되어 있기 때문에 선형 시간 소모, B-Tree는 모든 노드 확인</p>
<p>반면, B- Tree는 최상의 경우 특정 Key를 root node에서 찾을 수 있지만, B+Tree의 경우 반드시 leaf node까지 가야함.</p>
<p><img src="https://velog.velcdn.com/images/steel-hyuk/post/d697d53f-8719-4235-bb66-3db777c5beb8/image.png" alt=""></p>
<p>B+ Tree의 삽입</p>
<p>B+ Tree의 삭제</p>
<ul>
<li>B- Tree의 경우와 동일하나 B+ Tree는 leaf가 아닌 node에 중복값이 존재하기 때문에 해당 key를 노드보다 오른쪽에 있으면서 가장 작은 값으로 바꿔주어야 한다.</li>
</ul>
<p>B+ Tree의 수정</p>
<ul>
<li>삭제 후 삽입</li>
</ul>
]]></description>
        </item>
        <item>
            <title><![CDATA[[TIL] OSI 7계층과 TCP / IP 5계층]]></title>
            <link>https://velog.io/@steel-hyuk/TIL-OSI-7%EA%B3%84%EC%B8%B5%EA%B3%BC-TCP-IP-5%EA%B3%84%EC%B8%B5</link>
            <guid>https://velog.io/@steel-hyuk/TIL-OSI-7%EA%B3%84%EC%B8%B5%EA%B3%BC-TCP-IP-5%EA%B3%84%EC%B8%B5</guid>
            <pubDate>Thu, 12 Jan 2023 10:30:49 GMT</pubDate>
            <description><![CDATA[<h3 id="osi-7-layer">OSI 7 Layer</h3>
<p>(Open systems Interconnection)</p>
<p><strong>배경</strong></p>
<p>1980년대 컴퓨터 통신망이 확산되면서 여러 통신망이 공존하는 상황이었다.</p>
<p>통신규격 통일의 필요성을 느낀 ISO (국제 표준화기구)에서는 1984년 OSI 참조 모델을 발표한다.</p>
<p>이 모델은 서로 다른 컴퓨터 기기 간에 네트워크를 형성할 수 있도록 규정한 네트워크 모델 표준안이다.</p>
<p><strong>계층화</strong></p>
<p>모듈들이 계층을 이루도록 역할과 책임을 세분화 하는 것</p>
<p>ex) 항공 (매표소 - 수하물 - 게이트 - 활주로 - 비행기)</p>
<p>why? ⇒ </p>
<p>복잡한 시스템의 구조를 분리해서 명확하게 한다.</p>
<p>모듈화로 시스템의 관리와 갱신을 용이하게 한다.</p>
<p><em>너무 세부화된 계층은 오히려 기능을 복잡하게 만들 수 있다.</em></p>
<p>각 계층은 (                           ) 서비스를 구현한다.</p>
<ul>
<li>계층 자체의 내부 동작을 통해</li>
<li>하위 계층에서 제공되는 서비스에 의존하여</li>
</ul>
<p><img src="https://velog.velcdn.com/images/steel_hyuk___2/post/503b195a-f199-4d17-ba9d-060a1fdb6f07/image.png" alt=""></p>
<p>너무 세부화된 계층은 기능을 복잡하게 만듦 ⇒ OSI 7 계층은 이론적으로만 남게 됨.</p>
<p>실제로는 TCP/IP 프로토콜 계층을 사용함.</p>
<p>OSI : 서로 다른 컴퓨터 기기 간에 네트워크를 형성할 수 있도록 규정한 네트워크 모델 표준안</p>
<p>TCP/IP : 인터넷 프로토콜을 사용해서 인터네트워킹을 가능하게 하는 프로토콜의 suit </p>
<hr>
<h3 id="응용-계층-application-layer---7-계층">응용 계층 (Application Layer) - 7 계층</h3>
<p>사용자와 가장 밀접한 계층으로 인터페이스 역할</p>
<p>응용 프로세스 간의 정보 교환을 담당</p>
<p>예 : 전자메일, 웹, 문자 메시지, p2p파일 공유, 네트워크 게임, 비디오 스트리밍, 실시간 화상회의, SNS, 검색, …</p>
<p>서로 다른 종단 시스템에서 실행됨</p>
<p>프로세스 : 호스트에서 실행되는 프로그램</p>
<ul>
<li>한 호스트 내에서 두 프로세스는 IPC(Inter-process-communication)을 통해 통신</li>
<li>다른 호스트에 있는 프로세스들은 메시지를 교환함으로써 통신</li>
</ul>
<p>소켓 : 어플리케이션 프로세스를 그 밑에 있는 tcp/ip 프로토콜과 연결해주는 부분</p>
<ul>
<li>프로세스는 소켓을 통해 메시지를 주고 받는다.</li>
</ul>
<p><img src="https://velog.velcdn.com/images/steel_hyuk___2/post/e91594c8-5a99-4b32-9e54-0068073d9bad/image.jpeg" alt=""></p>
<p>메시지를 받기 위해 프로세스는 식별자가 필요하다. </p>
<p>호스트는 고유의 32-bit IP 주소를 가짐</p>
<p>(IP 주소만으로는 호스트 내에서 실행되는 프로세스를 식별할 수 없음)</p>
<p>⇒ 식별자 : port number</p>
<p>서버의 port number와 클라이언트의 port number는 별개다.</p>
<p>애플리케이션마다 중요하게 생각하는 것이 다름</p>
<ul>
<li>데이터 신뢰성<ul>
<li>어떤 응용은 100% 신뢰성 있는 데이터 전송을 요구한다. (파일전송)</li>
<li>다른 응용은 약간의 손실을 허용한다. (오디오)</li>
</ul>
</li>
<li>시간(timing)<ul>
<li>어떤 응용은 낮은 지연시간에서만 효과적</li>
</ul>
</li>
<li>처리율 (throughput)<ul>
<li>bps</li>
<li>어떤 응용은 최소한의 처리율이 충족되어야 함.</li>
<li>어떤 응용은 탄력적 응용 (이메일 : 1초 후에 도착하든지 2초 후에 도착하든지 상관없음)</li>
</ul>
</li>
<li>security<ul>
<li>암호화, 데이터 무결성 …</li>
</ul>
</li>
</ul>
<p>이러한 성격에 따라 소켓은 TCP 소켓 ? UDP 소켓 ? 어떤 걸 만들어야할지 제일 먼저 고민해야 함.</p>
<p>ㅁ 표현 계층 (Presentation Layer) - 6계층</p>
<p>데이터를 어떻게 표현할지 결정하는 역할 (데이터의 형식 결정)</p>
<p>송신자에게서 온 데이터를 해석하기 위한 데이터 부호화, 변화 담당</p>
<p>데이터 암호화 복호화</p>
<p>ㅁ 세션 계층 (Session Layer) - 5계층</p>
<p>통신 장치 간 상호작용 및 동기화 제공</p>
<hr>
<h3 id="전송-계층-transport-layer---4계층">전송 계층 (Transport Layer) - 4계층</h3>
<p>전송 계층의 주소 : IP + Port number </p>
<p>서로 다른 호스트의 프로세스들 간에 논리적 통신을 제공한다.</p>
<p>전송계층 프로토콜은 종단시스템에서 수행된다.</p>
<ul>
<li><p>송신측 : 메시지를 세그먼트로 쪼개서 네트워크 계층에 전달</p>
</li>
<li><p>수신측 : 세그먼트를 메시지로 재조립해서 애플리케이션 계층에 전달</p>
</li>
<li><p>UDP (User Datagram Protocol)</p>
<ul>
<li><p>best-effort service</p>
<ul>
<li>사라지거나 순서가 바뀌어 전달될 수 있다.</li>
</ul>
</li>
<li><p>비연결형</p>
<ul>
<li>송수신측 사이에 handshaking 없음</li>
</ul>
</li>
<li><p>스트리밍 멀티미디어 서비스, DNS, …</p>
<ul>
<li>손실을 허용하고 전송률에 민감함</li>
</ul>
</li>
<li><p>UDP segment header</p>
<ul>
<li>source port #, destination port #</li>
<li>length : 헤더를 포함한 UDP segment의 바이트 단위 길이</li>
<li>checksum : 에러가 있는지 없는지 체크하기 위한 정보</li>
</ul>
</li>
<li><p>송수신 프로세스 간의 비신뢰적 전송 (에러가 있다는 사실만 알려줌 ⇒ 응용 계층에서 알아서 해결)</p>
</li>
<li><p>제공하지 않는 것 : 신뢰성, 흐름 제어, 혼잡 제어, 시간보장, 처리율보장, 보안, 연결 설정</p>
</li>
<li><p>사용하는 이유 ? 단순하기 때문. 최대한 빨리빨리 !</p>
<p>대부분의 서비스에서 TCP를 사용. DNS 등 UDP 사용</p>
<p>예전에는 스트리밍 서비스에서 유실을 어느 정도 허용했기에 UDP를 사용했지만 요새는 TCP 사용 (버퍼 이용)</p>
</li>
</ul>
</li>
</ul>
<p>신뢰있게 데이터를 전송하는 원리 (Reliable Data Transfer)</p>
<ul>
<li>ACK<ul>
<li>acknowledgements (ACK) : 수신측이 받은 패킷이 OK라고 송신측에게 알림</li>
<li>negative acknowledgements (NAKs): 그 반대</li>
</ul>
</li>
<li>timeout</li>
</ul>
<p><img src="https://velog.velcdn.com/images/steel_hyuk___2/post/37785215-441c-4560-b318-6893dcf58788/image.jpeg" alt=""></p>
<ul>
<li><p>ACK / NAK가 손상되면 ?</p>
</li>
<li><p>송신측은 수신측에서 일어나는 일을 알 수 없다. 무작정 재전송하는 것도 불가 (중복 가능성)</p>
</li>
<li><p>⇒ 중복 처리 : 패킷에 순서번호를 추가</p>
</li>
<li><p>파이프라인 기법</p>
</li>
</ul>
<p><img src="https://velog.velcdn.com/images/steel_hyuk___2/post/e2e6c6f7-4668-41d2-96f3-ac0aaf279377/image.jpeg" alt=""></p>
<pre><code>   - in-flight로 전송하는 것을 허용
   - 순서 번호의 범위 증가
- go-back-n : 오류 난 곳부터 다시 받음
- selective repeat : 오류난 부분만 다시 받음</code></pre><ul>
<li>TCP (Transmission Control Protocol)<ul>
<li>송수신 프로세스 간의 신뢰성 있는 전송 (재전송)</li>
<li>흐름제어 : 수신측이 처리할 수 있는 속도에 맞춰 송신</li>
<li>혼잡제어 : 망이 혼잡해지면 송신측 속도를 낮춤<ul>
<li>AIMD : 처음에 패킷을 하나씩 보내고 문제 없다면 window 크기(단위 시간 내에 보내는 패킷의 수)를 점차 늘림</li>
<li>패킷 전송에 실패하거나 일정 시간이 넘으면 패킷의 보내는 속도를 줄임</li>
</ul>
</li>
<li>제공하지 않는 것 : 시간보장, 처리율 보장, 보안</li>
<li>연결지향형 서비스 : client-server 간 연결 설정 필요</li>
<li>guaranteed service</li>
<li>TCP segment<ul>
<li>source port #, destination port #</li>
<li>sequence number : 세그먼트 내 데이터의 첫 바이트의 번호</li>
<li>acknowledgement number : 상대로부터 기대하는 다음 바이트의 번호</li>
<li>checksum</li>
</ul>
</li>
<li>TCP Timeout 설정<ul>
<li>RoundTripTime을 고려(이것보다 길게)</li>
</ul>
</li>
</ul>
</li>
</ul>
<hr>
<h3 id="네트워크-계층-network-layer---3계층">네트워크 계층 (Network Layer) - 3계층</h3>
<p>네트워크 계층의 주소 : IP Address</p>
<p>라우팅 기능을 맡고 있는 계층</p>
<p>목적지까지 가장 안전하고 빠르게 데이터를 보낼 최적의 경로를 설정</p>
<p>송신 호스트에서 수신 호스트로 segment 전달</p>
<p>송신측에서는 segment를 datagram으로 캡슐화함</p>
<p>수신측은 트랜스포트 계층에 segment 전달</p>
<p>네트워크 계층의 두 가지 주요 기능</p>
<ul>
<li>routing<ul>
<li>패킷이 출발지에서 목적지까지 거칠 경로를 결정</li>
</ul>
</li>
<li>forwarding<ul>
<li>라우터의 입력으로 들어오는 패킷을 적절한 출력으로 보냄</li>
</ul>
</li>
</ul>
<p>네트워크 계층의 두 가지 영역</p>
<ul>
<li>제어 영역<ul>
<li>네트워크 전반의 로직</li>
<li>어떤 경로를 거칠지 결정</li>
</ul>
</li>
<li>데이터 영역<ul>
<li>개개의 라우터마다의 지역적 기능</li>
<li>라우터의 입력 포트에 도착한 datagram이 출력포트에 전달될 방법을 결정</li>
<li>forwarding 기능</li>
</ul>
</li>
</ul>
<p>각각의 라우터는 forwarding table을 가짐.</p>
<p>IP datagram 형식</p>
<ul>
<li>version, 헤더길이, 데이터 타입, time to live (남아있는 최대 hop수), upper layer(payload를 전달할 상위 계층 프로토콜), 전체 데이터그램 길이, (fragment offset, 16-bit identifier, flags)(단편화와 재결합을 위해 사용), checksum(헤더에 대해서만 오류확인), 출발지 IP 주소, 목적지 IP 주소, 옵션(타임스탬프, 거쳐간 경로 기록, 경유할 라우터 목록)</li>
</ul>
<p>단편화와 재결합</p>
<ul>
<li>네트워크 링크에는 MTU(max transfer size) 즉 frame의 최대 크기가 존재</li>
<li>큰 IP datagram은 네트워크 내에서 쪼개진다 (단편화)</li>
<li>쪼개진 datagram은 목적지에서 재결합된다.</li>
</ul>
<hr>
<h3 id="데이터-링크-계층-data-link-layer---2계층">데이터 링크 계층 (Data-Link Layer) - 2계층</h3>
<p>데이터링크 계층의 주소 : MAC Address</p>
<p>물리적인 연결을 통해 인접한 두 장치 간의 신뢰성 있는 정보 전송을 담당</p>
<p>주요 역할 : 프레이밍, 흐름 제어, 오류 제어, 접근 제어, 동기화</p>
<ul>
<li>흐름 제어 : 인접한 송수신 노드 간의 보조 맞추기</li>
<li>오류 검출<ul>
<li>신호 감쇄나 노이즈 등으로 인해 오류가 발생한다</li>
<li>수신측에서 오류의 존재를 검출한다 ⇒ 송신측에 재전송을 요구하거나 frame을 버린다</li>
</ul>
</li>
<li>오류 정정 : 수신 측이 비트 오류를 인식하면 재전송 없이 오류를 정정한다</li>
</ul>
<p>링크 계층은 랜카드에 상당 부분 구현됨. (모든 호스트에 각각 구현)</p>
<hr>
<h3 id="물리-계층-physical-layer---1계층">물리 계층 (Physical Layer) - 1계층</h3>
<p>전기적, 기계적, 기능적인 특성을 이용해 데이터를 전송</p>
<p>데이터를 전송하는 역할을 할 뿐, 알고리즘이나 오류제어의 기능이 없음</p>
]]></description>
        </item>
    </channel>
</rss>