<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>developer_chan.log</title>
        <link>https://velog.io/</link>
        <description></description>
        <lastBuildDate>Mon, 20 May 2024 11:10:12 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <image>
            <title>developer_chan.log</title>
            <url>https://velog.velcdn.com/images/developer_chan/profile/96bb94ad-5ca8-4b68-a192-2ec286116825/social_profile.png</url>
            <link>https://velog.io/</link>
        </image>
        <copyright>Copyright (C) 2019. developer_chan.log. All rights reserved.</copyright>
        <atom:link href="https://v2.velog.io/rss/developer_chan" rel="self" type="application/rss+xml"/>
        <item>
            <title><![CDATA[[ Querydsl ] exists를 어떻게 구현해야할까?]]></title>
            <link>https://velog.io/@developer_chan/Querydsl-exists%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EA%B5%AC%ED%98%84%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C</link>
            <guid>https://velog.io/@developer_chan/Querydsl-exists%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EA%B5%AC%ED%98%84%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C</guid>
            <pubDate>Mon, 20 May 2024 11:10:12 GMT</pubDate>
            <description><![CDATA[<p>우리는 querydsl을 통해 exists를 구현하고는 한다 
이 exists를 구현할 때 우리는 어떻게 구현하는 것이 좋을지 알아보려고 한다.</p>
<h2 id="1-fetchcount">1. fetchCount()</h2>
<pre><code>public Boolean findByMember(Entity entity) {
        return queryFactory.selectFrom(entity)
                .where(entity.eq(entity))
                .fetchCount()&gt;0;
    }</code></pre><p>위와 같이 count를 한 후 그 결과가 1보다 큰지 확인하는 방법이 있다.
그러나 이 방법은 결국 모두 조회한 후 0보다 큰지 확인하기 때문에 성능적으로 비효율적이다.</p>
<h2 id="2exists">2.exists()</h2>
<p>일반 query의 exists는 분명 효율적이다
그러나 querydsl의 exists는 이상하게도 fetchCount를 사용하는 위의 방법과 같이 구현되어있다.
그럼 우리는 대체 어떻게 구현해야할까?</p>
<h2 id="3fetchfirst">3.fetchFirst()</h2>
<pre><code>public Boolean findByMember(Entity entity) {
        return queryFactory.selectFrom(entity)
                .where(entity.eq(entity))
                .fetchFirst()!=null;
    }</code></pre><p>과 같이 구현하면 조회를 하며 하나라도 조건에 맞는 칼럼을 발견하면 
즉시 탐색을 종료하므로 최악의 경우에는 fetchCount()를 사용한 것과 같은 성능을 보여줄 수도 있으나 전체적으로 보았을 때에는 분명 더 좋은 성능을 보여줄 수 있을 것이다.</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[프로토콜과 OSI 7계층]]></title>
            <link>https://velog.io/@developer_chan/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EA%B3%BC-OSI-7%EA%B3%84%EC%B8%B5</link>
            <guid>https://velog.io/@developer_chan/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EA%B3%BC-OSI-7%EA%B3%84%EC%B8%B5</guid>
            <pubDate>Mon, 25 Mar 2024 11:26:09 GMT</pubDate>
            <description><![CDATA[<h3 id="프로토콜이란-무엇일까">프로토콜이란 무엇일까?</h3>
<p>프로토콜을 알아보기 전에 네트워크의 기능을 알아봐야하는데
네트워크의 기능은 아래와 같다.</p>
<blockquote>
</blockquote>
<ol>
<li>애플리케이션 목적에 맞는 통신 방법 제공</li>
<li>신뢰할 수 있는 데이터 전송 방법 제공</li>
<li>네트워크 간의 최적의 통신 경로 결정</li>
<li>목적지로 데이터 전송</li>
<li>노드 간 데이터 전송</li>
</ol>
<p>이런 여러개의 기능을 준수하며 통신 기능이 제대로 작동하기 위해 
통신자 간에 약속된 규칙/규약이 있어야하는데 이것을 <strong>프로토콜</strong>이라고 한다.</p>
<h3 id="왜-osi-7계층과-같이-네트워크-구조가-생겼을까">왜 OSI 7계층과 같이 네트워크 구조가 생겼을까?</h3>
<p>위에서 설명한 프로토콜을 구현할 때 하나의 프로토콜에서 5개의 기능을 모두 구현하는 것은 비효율적이라고 할 수 있다.
그렇기 때문에 OSI 7계층처럼 모듈화를 해야한다.</p>
<p>모듈화의 종류는 대표적으로는 2가지가 있는데 아래와 같다.</p>
<ul>
<li>OSI 7계층 : 범용적인 네트워크 구조</li>
<li>TCP/IP stack(4계층) : 인터넷에 특화된 구조</li>
</ul>
<h3 id="osi-7계층에-대해서">OSI 7계층에 대해서</h3>
<p>OSI 7계층은 위에서 기술한 네트워크 기능을 7단계로 쪼개 구현한 것이다.
또한, OSI 7계층은 아래 계층의 기능을 이용해 기능을 구현하는 방식을 가지고 있다.</p>
<h4 id="application-layer">application layer</h4>
<p>애플리케이션 목적에 따라 HTTP, DNS, SMTP, FTP와 같은 통신 방식을 제공한다.</p>
<h4 id="presentation-layer">presentation layer</h4>
<p>애플리케이션 통신 간에서 데이터 포맷 형식을 관리한다.</p>
<ul>
<li>인코딩 - 디코딩</li>
<li>암호화 - 복호화<h4 id="senssion-layer">senssion layer</h4>
애플리케이션 통신 간에서 세션을 관리함<h4 id="transport-layer">transport layer</h4>
애플리케이션 통신 간에서 목적지로 데이터를 전송함
TCP : 안전하고 신뢰할 수 있는 데이터만 전송
UDP : 아무튼 모든 데이터 전송<h4 id="nwtwork-layer">nwtwork layer</h4>
IP를 통한 호스트로의 전송을 담당함
또한, 네트워크 간 최적의 경로를 계산함<h4 id="datalink-layer">datalink layer</h4>
MAC 주소를 통해직접 연결된 노드 간의 통신 담당<h4 id="physical-layer">physical layer</h4>
bits 값으로 데이터 전송</li>
</ul>
<h3 id="전체적인-과정">전체적인 과정</h3>
<p>엔드 노드에서 application layer부터 physical layer까지 캡슐화를 하고
physical layer에서 bits를 통해 라우터로 전송된 후,
network layer까지 비캡슐화하여 경로를 설정하고 다시 physical layer까지 캡슐화하여
다음 라우터들을 거쳐 같은 과정을 반복한다.
그리고 목적지 엔드 노드까지 도달하면 application layer까지
비캡슐화하여 데이터 전송을 끝낸다.</p>
<h3 id="tcpip와-osi-7계층의-차이점">tcp/ip와 OSI 7계층의 차이점</h3>
<p>tcp/ip에서는 OSI 7계층의 
application layer, presentation layer, senssion layer
를 application layer 하나로 담당하고
datalink layer, physical layer를 
datalink layer 하나로 담당한다.</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[Internet에 대해]]></title>
            <link>https://velog.io/@developer_chan/Internet%EC%97%90-%EB%8C%80%ED%95%B4</link>
            <guid>https://velog.io/@developer_chan/Internet%EC%97%90-%EB%8C%80%ED%95%B4</guid>
            <pubDate>Thu, 21 Mar 2024 02:13:48 GMT</pubDate>
            <description><![CDATA[<h3 id="internet이란-무엇일까">internet이란 무엇일까?</h3>
<p>internet은 네트워크들의 네트워크이며, 세상에서 가장 큰 WAN이라고도 말한다.</p>
<h3 id="isp란">ISP란?</h3>
<p>ISP는 일반 사용자 혹은 기관, 회사 등이 인터넷을 사용할 수 있도록 
인터넷을 연결시켜주는 서비스를 제공해주는 것들이다.</p>
<h3 id="isp에도-tier가-있다고">ISP에도 tier가 있다고?</h3>
<p>ISP에도 tier가 있다는데 1,2,3 tier로 나뉜다고 한다.</p>
<h4 id="tier-1">tier 1</h4>
<ul>
<li>전역적인 범위의 네트워크를 지니고 있음</li>
<li>모든 네트워크에 접근할 수 있으며 주로 인터넷의 중추 역할을 함</li>
<li>트래픽에 대한 전송 비용이 없음<h4 id="tier-2">tier 2</h4>
</li>
<li>일반 사용자 또는 기업 등을 상대로 주로 서비스 함</li>
<li>전역적으로 서비스를 제공하기 위해 tier1에게 전송비용을 지불하고 서비스함</li>
<li>tier2 끼리는 트래픽 전송 비용이 없는 경우도 있음<h4 id="tier-3">tier 3</h4>
</li>
<li>tier2와 같이 일반 사용자 또는 기업 등을 상대로 주로 서비스 함</li>
<li>tier2에게 트래픽을 구입해 서비스를 제공한다.</li>
</ul>
<h3 id="라우터">라우터</h3>
<p>여기서 의문을 하나 가질 수 있는데 tier1, tier2, tier3 간의 통신을 어떻게 하는지이다.
이것은 라우터를 통해 해결하는데 라우터는 네트워크 간의 데이터를 보내도록 해주는 장치라고 볼 수 있다.
예를 들어보자면 집과 회사간의 네트워크 통신을 한다고 하면
집 -&gt; tier2 네크워크 -&gt; tier1네크워크 -&gt; tier2네트워크 -&gt; 회사
이런식인 것이다.</p>
<h3 id="node">node</h3>
<p>네트워크에서 노드는 네트워크를 구성하는 모든 장치를 뜻하는데
예를 들어 라우터, 컴퓨터, 서버컴퓨터, TV 등이 모두 노드이다.</p>
<h4 id="endpoint-node">endpoint node</h4>
<p>엔드포인트 노드는 노드들 중 네크워크의 끝에 있는 노드로 네트워크를 
사용하기 위해 사용 된다.</p>
<h5 id="clinet-vs-server">clinet vs server</h5>
<p>이때 엔드포인트 노드는 client와 server로 나뉘는데 요청을 보내는 쪽을 client, 
요청을 받고 데이터를 주는 쪽을 server 라고 한다.</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[LAN과 WAN]]></title>
            <link>https://velog.io/@developer_chan/LAN%EA%B3%BC-WAN</link>
            <guid>https://velog.io/@developer_chan/LAN%EA%B3%BC-WAN</guid>
            <pubDate>Mon, 18 Mar 2024 14:48:05 GMT</pubDate>
            <description><![CDATA[<p>저번 게시물에서는 home network에 대해 알아봤는데 
이번 게시물에서는 network와 함께 network의 종류에 대해 알아보자.</p>
<h3 id="network-는-뭘까">NETWORK 는 뭘까?</h3>
<p>network는 서로 다른 컴퓨터 또는 그 외의 다른 기기들을 연결해 데이터를 공유할 수 있도록 유선 혹은 무선으로 연결된 데이터 전송 체계를 뜻한다.</p>
<h3 id="lan-은-뭘까">LAN 은 뭘까?</h3>
<p>LAN은 Local Area Network의 줄임말로 제한된 일정 구역 내에서 데이터를 공유할 수 있도록 하는 네트워크를 뜻한다.</p>
<blockquote>
<p>LAN의 종류
유선통신 : Ethernet
무선통신 : wireless LAN(wi-fi)</p>
</blockquote>
<h3 id="wan은-뭘까">WAN은 뭘까?</h3>
<p>WAN은 LAN 또는 다른 종류의 네트워크 사이를 이어 데이터를 공유할 수 있도록 하는 네트워크로 LAN보다 더욱 넓은 범위를 이어주는 네트워크라고 볼 수 있다.</p>
<blockquote>
<p>WAN의 종류
ATM, wireless WAN, Internet 등이 있다.</p>
</blockquote>
]]></description>
        </item>
        <item>
            <title><![CDATA[Home Network]]></title>
            <link>https://velog.io/@developer_chan/Home-Network</link>
            <guid>https://velog.io/@developer_chan/Home-Network</guid>
            <pubDate>Mon, 18 Mar 2024 14:39:49 GMT</pubDate>
            <description><![CDATA[<h3 id="ip-주소">ip 주소</h3>
<p>네트워크에 접근하기 위해 필요한 인터넷 상의 주소</p>
<h3 id="모뎀">모뎀</h3>
<p>네트워크 통신을 위해 필요한 신호 변환 장치</p>
<h3 id="공유기">공유기</h3>
<p>여러 기기를 하나의 네트워크에 연결시키기 위한 장치로 
한 공유기를 통해 연결된 기기는 모두 같은 네트워크를 가짐
고로, 한 ip주소를 통해 모두 접속이 가능</p>
<blockquote>
<p>if 공유기의 랜선 포트가 부족하면 더 이상 하나의 네트워크에 더 많은 기기를 속하게 하지 못하는 걸까?
-&gt; 스위치를 통해 해결가능</p>
</blockquote>
<h3 id="스위치">스위치</h3>
<p>스위치는 주로 포트의 개수가 부족할 때 자주 사용하며, 같은 네트워크 내의 기기가 데이터를 주고 받으며 통신할 수 있도록 함</p>
]]></description>
        </item>
        <item>
            <title><![CDATA[process와 thread]]></title>
            <link>https://velog.io/@developer_chan/process%EC%99%80-thread</link>
            <guid>https://velog.io/@developer_chan/process%EC%99%80-thread</guid>
            <pubDate>Wed, 15 Nov 2023 10:33:19 GMT</pubDate>
            <description><![CDATA[<h2 id="process란">process란?</h2>
<ul>
<li>process : 운영체제로부터 자원을 할당받은 *<em>작업의 단위    *</em>
&ensp;&ensp;&ensp;&ensp;&ensp;&ensp;&ensp;&ensp;&ensp;&ensp;메모리에 올라와 실행되고 있는 프로그램의 인스턴스<blockquote>
<p><em>참고 : 할당받는 시스템 자원의 예시</em></p>
</blockquote>
<ul>
<li><em>CPU 시간</em></li>
<li><em>주소 공간(memory)</em></li>
<li><em>Code, Data, Stack, Heap의 구조로 되어 있는 독립된 메모리 영역</em></li>
</ul>
</li>
<li>특징<ul>
<li>프로세스는 각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다.</li>
<li>기본적으로 프로세스당 최소 1개의 스레드(메인 스레드)를 가지고 있다.</li>
<li>각 프로세스는 별도의 주소 공간에서 실행됨.</li>
<li>한 프로세스는 다른 프로세스의 변수나 자료구조에 접근할 수 없다.</li>
<li>한 프로세스가 다른 프로세스의 자원에 접근하려면 프로세스 간의 통신(socket, 파이프 등)을 사용해야 함</li>
</ul>
</li>
</ul>
<h2 id="thread란">thread란?</h2>
<ul>
<li><p>thread : 프로세스가 할당받은 자원을 이용하는 <strong>실행 흐름의 단위</strong></p>
</li>
<li><p>특징</p>
<ul>
<li>스레드는 프로세스 내에서 각각 Stack만 따로 할당받고 Code, Data, Heap 영역은 공유한다. </li>
<li>스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 프로세스 내의</li>
<li>주소 공간이나 자원들(힙 공간 등)을 같은 프로세스 내에 스레드끼리 공유하면서 실행된다. </li>
<li>같은 프로세스 안에 있는 여러 스레드들은 같은 힙 공간을 공유한다. 반면에 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다. 각각의 스레드는 별도의 레지스터와 스택을 갖고 있지만, 힙 메모리는 서로 읽고 쓸 수 있다.</li>
<li>한 스레드가 프로세스 자원을 변경하면, 다른 이웃 스레드(sibling thread)도 그 변경 결과를 즉시 볼 수 있다.</li>
</ul>
</li>
</ul>
<h2 id="멀티-프로세스">멀티 프로세스</h2>
<ul>
<li>하나의 응용프로그램을 여러 개의 프로세스로 구성하여 각 프로세스가 하나의 작업(태스크)을 처리하도록 하는 것이다.</li>
</ul>
<ul>
<li>장점 <ul>
<li>여러 개의 자식 프로세스 중 하나에 문제가 발생하면 그 자식 프로세스만 죽는 것 이상으로 다른 영향이 확산되지 않는다.</li>
</ul>
</li>
<li>단점<ul>
<li>Context Switching에서의 오버헤드</li>
<li>Context Switching 과정에서 캐쉬 메모리 초기화 등 무거운 작업이 진행되고 많은 시간이 소모되는 등의 오버헤드가 발생하게 된다.</li>
<li>프로세스는 각각의 독립된 메모리 영역을 할당받았기 때문에 프로세스 사이에서 공유하는 메모리가 없어, Context Switching가 발생하면 캐쉬에 있는 모든 데이터를 모두 리셋하고 다시 캐쉬 정보를 불러와야 한다.</li>
<li>프로세스 사이의 어렵고 복잡한 통신 기법(IPC)</li>
<li>프로세스는 각각의 독립된 메모리 영역을 할당받았기 때문에 하나의 프로그램에 속하는 프로세스들 사이의 변수를 공유할 수 없다.<blockquote>
<p>참고 : Context Switching란?</p>
<ul>
<li>CPU에서 여러 프로세스를 돌아가면서 작업을 처리하는 데 이 과정을      Context Switching라 한다.</li>
<li>구체적으로, 동작 중인 프로세스가 대기를 하면서 해당 프로세스의 상태&gt;(Context)를 보관하고, 대기하고 있던 다음 순서의 프로세스가 동작하면서 이전에 보관했던 프로세스의 상태를 복구하는 작업을 말한다.</li>
</ul>
</blockquote>
</li>
</ul>
</li>
</ul>
<h2 id="멀티-스레드">멀티 스레드</h2>
<ul>
<li>멀티 스레딩이란<ul>
<li>하나의 응용프로그램을 여러 개의 스레드로 구성하고 각 스레드로 하여금 하나의 작업을 처리하도록 하는 것이다.</li>
<li>윈도우, 리눅스 등 많은 운영체제들이 멀티 프로세싱을 지원하고 있지만 멀티 스레딩을 기본으로 하고 있다.</li>
<li>웹 서버는 대표적인 멀티 스레드 응용 프로그램이다.</li>
</ul>
</li>
<li>장점<ul>
<li>시스템 자원 소모 감소 (자원의 효율성 증대)</li>
<li>프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어 자원을 효율적으로 관리할 수 있다.</li>
<li>시스템 처리량 증가 (처리 비용 감소)</li>
<li>스레드 간 데이터를 주고 받는 것이 간단해지고 시스템 자원 소모가 줄어들게 된다.</li>
<li>스레드 사이의 작업량이 작아 Context Switching이 빠르다.</li>
<li>간단한 통신 방법으로 인한 프로그램 응답 시간 단축</li>
<li>스레드는 프로세스 내의 Stack 영역을 제외한 모든 메모리를 공유하기 때문에 통신의 부담이 적다.</li>
</ul>
</li>
<li>단점<ul>
<li>주의 깊은 설계가 필요하다.</li>
<li>디버깅이 까다롭다.</li>
<li>단일 프로세스 시스템의 경우 효과를 기대하기 어렵다.</li>
<li>다른 프로세스에서 스레드를 제어할 수 없다. (즉, 프로세스 밖에서 스레드 각각을 제어할 수 없다.)</li>
<li>멀티 스레드의 경우 자원 공유의 문제가 발생한다. (동기화 문제)</li>
<li>하나의 스레드에 문제가 발생하면 전체 프로세스가 영향을 받는다.</li>
</ul>
</li>
</ul>
<h2 id="멀티-프로세스-대신-멀티-스레드를-사용하는-이유">멀티 프로세스 대신 멀티 스레드를 사용하는 이유</h2>
<ul>
<li>프로그램을 여러 개 키는 것보다 하나의 프로그램 안에서 여러 작업을 해결하는 것이다.</li>
<li>여러 프로세스(멀티 프로세스)로 할 수 있는 작업들을 하나의 프로세스에서 여러 스레드로 나눠가면서 하는 이유<ul>
<li>자원의 효율성 증대
멀티 프로세스로 실행되는 작업을 멀티 스레드로 실행할 경우, 프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어 자원을 효율적으로 관리할 수 있다.
–&gt; 프로세스 간의 Context Switching시 단순히 CPU 레지스터 교체 뿐만 아니라 RAM과 CPU 사이의 캐쉬 메모리에 대한 데이터까지 초기화되므로 오버헤드가 크기 때문
스레드는 프로세스 내의 메모리를 공유하기 때문에 독립적인 프로세스와 달리 스레드 간 데이터를 주고 받는 것이 간단해지고 시스템 자원 소모가 줄어들게 된다.</li>
<li>처리 비용 감소 및 응답 시간 단축
또한 프로세스 간의 통신(IPC)보다 스레드 간의 통신의 비용이 적으므로 작업들 간의 통신의 부담이 줄어든다.
–&gt; 스레드는 Stack 영역을 제외한 모든 메모리를 공유하기 때문
프로세스 간의 전환 속도보다 스레드 간의 전환 속도가 빠르다.
–&gt; Context Switching시 스레드는 Stack 영역만 처리하기 때문</li>
</ul>
</li>
</ul>
]]></description>
        </item>
    </channel>
</rss>